Recommended Standards

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE
For Quadrant:
Retail Electric Quadrant
Requesters:
Smart Grid Interoperability Panel
Request No.:
2010 Retail Annual Plan Item 9(c)
Request Title:
Phase Two Requirements Specification for
Retail Standard DR Signals for NIST PAP09
1. RECOMMENDED ACTION:
X
X
Accept as requested
Accept as modified below
Decline
EFFECT OF EC VOTE TO ACCEPT

RECOMMENDED ACTION:
X
Change to Existing Practice

Status Quo
2. TYPE OF DEVELOPMENT/MAINTENANCE
Per Request:
Initiation
X
Modification
Interpretation
Withdrawal
X
X
X
Principle
Definition
Business Practice Standard
Document
Data Element
Code Value
X12 Implementation Guide
Business Process Documentation
Per Recommendation:
Initiation
X
Modification
Interpretation
Withdrawal
X
X
X
Principle
Definition
Business Practice Standard
Document
Data Element
Code Value
X12 Implementation Guide
Business Process Documentation
3. RECOMMENDATION
SUMMARY:
The business process flows, use cases and data requirements presented in this document
illustrate the standard interactions between Utility Distribution Operator, Service Provider
(Demand Response) and Utility Customer for the administration and deployment of
demand response resources retail markets.
RECOMMENDED STANDARDS:
In response to NISTs Priority Action Plan 9, this document provides requirements
specification, in the form of business process flows, use cases and data requirements in
certain areas, to support the standardization of the information exchange between Utility
Distribution Operator, Service Provider (Demand Response) and Utility Customer. This
document shares a standard set of actors and terminologies with the companion
Requirements Specification for Wholesale Standard DR Signals.
Draft Recommendation October 14, 2010

Page 1

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.2.B
New REQ.17.2.B Defined Terms to be added to REQ.17 are included
in the Recommendation Request Titled Phase Two Requirements
Specification for Common Electricity Product and Pricing Definition
for NIST PAP03 to avoid redundancy between recommendations.
RECOMMENDED STANDARDS:
Executive Summary
Specifications for Retail Standard Demand Response Signals
The North America Energy Standards Board (NAESB) Smart Grid Standards Subcommittee
took the responsibility of consolidating and developing DR use cases that provide
requirements for developing DR control and pricing signal standards, which is called for by
National Institute of Standards and Technology (NIST) Priority Action Plans (PAP) 03 and
09. This document addresses the business and data requirements for standardizing
control and pricing signals for Retail level Demand Response (DR) and Distributed Energy
Resources (DER) as part of the Smart Grid implementation. Wholesale market DR and
DER information exchanges are outside the scope of this document and are addressed in
the Requirements Specification for Wholesale DR signals. The first step of use case
development is the development of the Framework for Integrated DR and DER Models
document, which provides an overall business context for DR and DER Models.
According to the Framework Document findings:
1. DR signals standardization must support all four market types; i.e. regions with a) no
open wholesale and no retail competition, b) open wholesale market only, c) open retail
competition only, d) open wholesale and open retail competition. It must also consider
key differences that exist and will continue to exist in all four market types.
2. Wholesale market DR and pricing signals have different characteristics than retail
market DR and pricing signals, although commonality in format is feasible.
3. Most Customers (with a few exception of Commercial and Industrial (C&I) Customers)
will not interact directly with wholesale market when it comes to DR and pricing signals.
4. Retail pricing models are complex, due to the numerous tariff rate structures that exist
in both regulated and un-regulated markets. Attempts to standardize DR control and
pricing signals must not hinder regulatory changes or market innovations when it comes
to future tariff or pricing models.
5. New business entities (Energy Service Providers (ESP), Demand Response Providers
(DRP), Service Providers, and Energy Information Service Providers (ESIP)) as well as
new customer energy management systems will play an increasing role in DR
implementation.
6. DER may play an increasingly important role in DR, yet the development of tariff and/or
pricing models that support DERs role in DR is still in its infancy.
Page 2

For Quadrant:
Requesters:
Request No.:
Request Title:
7. The Customers perspective and ability to react to DR control and pricing signals must
be a key driver during the development of DR standards.
The following deals exclusively with the retail level demand response signals requirements.
The requirements are captured in the form of UML models, where business requirements are
captured in Use Case narrative format, data requirements are captured in tabular format, and
information exchange flows are captured in sequence diagram format. The top level use
cases for retail DR are:
1.
2.
3.
4.
5.
Administrate DR Program
Administrate Customer for DR
Administrate DR Resource
Execute DR Event
Post DR Event Management
Introduction
This Model Business Practice and data elements included herein are not intended to replace
applicable Governing Documents, and in the event of a conflict, the latter documents shall
have precedence over this Model Business Practice.
Purpose: The purpose of the following is to capture business and data requirements for Retail
Level DR signals between entities that control and manage the DR programs and entities that
provide demand response with DR resources and assets. This is to fulfill the NAESB SGTF
responsibility under the NIST Smart Grid Interoperability Standards development PAP09. This
requirements document will then be used by other standards development organizations
identified by NIST PAP09 for further development of DR signals technical specifications for
both C&I customer and residential customer markets.
Scope: The scope of the following is to provide business and data requirements for
standardizing Demand Response signals at the retail (distribution) level.
Commentary on Distributed Energy Resources: In the context of this report, Distributed
Energy Resources (DER) are dispatchable energy generation and storage
technologies, typically up to ten MWs in size, that are interconnected to the distribution
grid to provide electric capacity and/or energy to a customer or a group of customers
and potentially export the excess to the grid for economical purposes. DER systems
can generate electric power, as opposed to curtailable or interruptible loads that can
just reduce electric loading on the grid.
DER may be subdivided into distributed generation (DG), distributed storage, and plug-in
electric vehicles (PEVs):
Distributed generation (DG) technologies can be divided into a) Renewable Generation, e.g.,
small wind power systems, solar photovoltaic (PV), Fuel Cells, Bio-fuel generators and
Digesters, and other generation resources using renewable fuel, and b) Non-Renewable
Page 3

For Quadrant:
Requesters:
Request No.:
Request Title:
Generation, e.g., micro-turbines, small combustion turbines, diesel, natural gas and dualfueled engines, etc.
Storage resources could be divided into a) Electric Storage, e.g., battery systems and
uninterruptible power supplies (UPS), flywheel, superconducting magnetic energy storage
(SMES), etc. and b) Thermal Storage These convert electric power to thermal
(cooling/heating) energy for later use, e.g., Ice-based air cooling system, and high-capacity
brick-based air heating system.
Plug-in electric and hybrid vehicles (PEV/PHEV) may also be considered as DER, The electric
vehicles may be used to supply stored electric energy back to the grid, a.k.a. Vehicle-to-grid
(V2G).
Behind-the-meter DER may be bundled with regular load and managed alongside the demand
response resources such as a residential roof-top PV solar panel. But often, DER is treated
separately in part due to its control capabilities. In addition to a regular retail tariff, behind-themeter DER may be subject to net-metering or feed-in tariff, where excess generation can be
exported to the grid at an established or a dynamic price.
Similar to DR resources, DER assets need to be registered and enrolled into a DR program.
Furthermore, DER assets are typically required to meet additional technical requirements and
certification for grid interconnection. Depending on the size of a DER and its export
capabilities, sub-metering and telemetry capabilities may be required to monitor the impact of
the DER operation on the distribution grid reliability and power quality.
Also, renewable
resources may receive Renewable Energy Credits (RECs) and may also qualify as a must-run
resource, e.g., wind power in some regions. These need to be incorporated into pricing and
control signals associated with DER operation.

Page 4

For Quadrant:
Requesters:
Request No.:
Request Title:
Model Business Practices

REQ.17.3.1

The following describes general business processes for implementing demand
response capacities at the retail market level. The following principles apply to
the development and application of these business process requirements.
#
1
Name
Scalability
Description
The architecture
should allow for the
management of
millions of Customer
premises devices
Actionable,
testable, and
transferable work
products
Any work (artifacts)

that are created can be
used by the audience
for this work, e.g.,
utilities, vendors,
regulators, etc. There
needs to be clear,
explicit guidance for
how to use the
artifacts. There is an
expectation that the
work products are
useful at lower levels
of design.
Rationale
Scale-out, adding
more low-cost
machines, has
proven to be
superior to scaleup, using larger
single machines,
as a way to handle
large loads. For
example, high
traffic web sites
use farms of lowcost machines to
serve pages to
millions of
simultaneous web
users.
Such work
products will
promote market
adoption and
minimize the cost
and risk of
adoption, leverage
open and best
practices, and
establish
repeatable
processes,
patterns, and
templates for all
work products.
Implication
Architecture should
allow the solution to
scale-out as more
devices are added.
The use of common

tools and methods
will be fostered.
Organizations that
do not follow the
use of the common
tools and methods
may have more
difficulty
implementing the
artifacts.

Page 5

For Quadrant:
Requesters:
Request No.:
Request Title:
#
3
Name
Platform
Independence,
Vendor Neutral
Description
Requirements and
design artifacts shall
be platform
independent.
Implementation
technology shall be
chosen due to its level
of acceptance at the
marketplace as open
standards.
Rationale
There is an
expectation of
differentiation and
innovation in the
marketplace. With
greater
dependence on a
specific platform,
there may be less
architectural
flexibility.
Cyber Secure
Architecture must
incorporate latest
secure computing
techniques.
The integrity of the

electric grid and
market depend on
preventing
unauthorized
actors from
manipulating the
DR and DER
system.
Interoperability
DR signaling standards
should utilize open,
interoperable industry
standard control and
communication
technologies to
integrate with both
common energy
management and
control systems that
can conduct DR
activities
Interoperability
across different
domains of Smart
Grid is key to the
success of DR
signaling
standards as it
ensures level
playing field for
innovative
solutions for all
participants of the
Smart Grid.
Implication
To achieve both
technical and
semantic
interoperability,
certain lower level
technologies will
need to be chosen.
For example, Web
Services
technology is widely
used for integration,
and UML is widely
used for modeling.
Architecture must
comply with the
latest security
guidance from the
NIST SGIP
Architecture
Committee and
CyberSecurity Task
Group, when it
comes to Web
Services security
related
implementation.
DR signaling
standards must be
developed in
harmonization with
others relevant
standards as
identified by the
NIST SGIP.

Page 6

For Quadrant:
Requesters:
Request No.:
Request Title:
#
6
Name
Automatic
Demand
Response
Cover All Market

Types
REQ.17.3.1.1
Description
The DR program
(analysis, notification,
event, action,
monitoring,
verification,
settlement) should be
automatic. DR
signaling standards
should provide secure,
reliable
communications with
consumers for DR
operations
DR signaling standards
should be supported
and implementable in
all four market types
listed in this document
Rationale
Automation is the
only way to ensure
large scale and
repeatable
demand response
implementation.
Implication
Security, reliability
and testability must
be ensured for DR
automation.
Standards
development shall
not get in the way
of regulatory policy
decisions.
DR signals design
need to support a
wide range of
programs and
tariff/pricing
structures.
Conventions
The use case modeling technique is used for capturing business and date
requirements relative to Retail Demand Response. There are two basic
diagrams used in this document. The first one is the use case diagram,
which shows the scope of business use cases for a given business
scenario. The relationships used in the Use Case diagrams are as follows:
Include: this indicates additional scenarios

Extend: this indicates alternatives scenarios
Generalization (line with triangle head): this indicates variations (subtypes) of the main use case.
Precedes: this indicates a time sequence
Invokes: this indicates a pre-condition or dependency
The second is the sequence diagram, which shows the information

exchange flows between actors for a given use case. The message flows
are shown in one way with the convention of verb and noun, verb indicating
the action being taken, noun indicating the name of the information being
exchanged. The return message flow is the acknowledgement of the main
message flow.
REQ.17.3.1.2 ACTORS
The actors listed in the table below are specific to this Model Business
Practice and are a subset of the actors and related objects defined in WEQDraft Recommendation October 14, 2010
Page 7

For Quadrant:
Requesters:
Request No.:
Request Title:
000. Details on the relationships between the actors and related objects are
further defined in Appendix A.
Table 1 - Actor Roles
Term
Actor ID1
Communication Method
5.5
Control
5.2
Designated Dispatch Entity
3.4
Designated Dispatch Entity

(DDE)
3.4
End Device (ED)
4.5
Enrollment
5.3
Environmental Authority
(EA)
1.3
Federal Regulator (FR)
1.1
Load Serving Entity
3.2
Load Serving Entity (LSE)
3.2
Local Authority (LA)
1.5
Market Participant (MP)
2.2
The Actor ID shown in the table refers to the item number of the corresponding actor or related object
in the Entity-Relationship Diagram provided in Appendix A. Definitions of the actors and related objects
are included in REQ.17.2
Page 8
1

For Quadrant:
Requesters:
Request No.:
Request Title:
Term
Actor ID
Measurement
5.1
Metering Authority
3.6
Metering Authority (MA)
3.6
P-Node
5.6
PremiseService Location
4.3
Reliability Authority (RA)
1.2
Resource
4.1
Scheduling Entity
3.3
Scheduling Entity (SE)
3.3
Service Provider
3.1
Service Provider (SP)
3.1
State Regulator (SR)
1.4

Page 9

For Quadrant:
Requesters:
Request No.:
Request Title:
Term
REQ.17.3.1.3
Actor ID
System Operator
2.1
Transmission/Distribution
Service Provider
3.5
Service Provider (TDSP)
3.5
Utility Customer (UC)
2.4
Utility Distribution Operator

(UDO)
2.3
Zone
5.4
Use Case Overview

Similar to the Wholesale Demand Response use cases, Retail Demand
Response use cases generally follow five main steps, see the Figure 1 2.
1. Administrate DR Program
2. Administrate Customer for DR
3. Administrate DR Resource
4. Execute DR Event
5. Post DR Event Management
There are many programs that exist in todays retail markets with or without
open competition. New programs will be defined and deployed in the future.
The goal of this use case analysis is to find commonalities among these
programs so that the derived DR signal messaging specification can be
implemented to support a large number of DR programs.
DR program administration related use cases are determined by the SGTF as out of scope for the NIST
PAP09 purpose, and therefore the original content has been removed from the final recommendation
and resulting Model Business Practices presented here. NAESB may start a new project to deal with the
customer enrollment and DR program administration related business practices.
Page 10
2

For Quadrant:
Requesters:
Request No.:
Request Title:
The focus of the Standardized DR Signals is the step 4, Execute DR Event,
where the DR signals will be communicated between the DR Providers and
the DR resources. All other use cases are supporting materials to ensure
that DR use case requirements are documented and understood in a
complete picture.
The use cases included in this document are not intended to be required or
exhaustive and are provided for clarification purposes.
Figure 1. Retail Market DR Use Case Overview

Page 11

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4
Specific Use Cases
REQ.17.3.1.4.1
Administrate DR Program
DR program administration related use cases are determined by the
SGTF as out of scope for the NIST PAP09 purpose, and therefore
the original content has been removed from the final
recommendation and resulting Model Business Practices presented
here. NAESB may start a new project to deal with the customer
enrollment and DR program administration related business
practices.
REQ.17.3.1.4.2
Administrate Customer for DR

DR program customer enrollment related use cases are determined
by the SGTF as out of scope for the NIST PAP09 purpose, and
therefore the original content has been removed from the final
recommendation and resulting Model Business Practices presented
here. NAESB may start a new project to deal with the customer
enrollment and DR program administration related business
practices.
REQ.17.3.1.4.3
Administrate DR Resource
DR Resource is an equivalent of Resource defined in the actor list
table.
As part of enrolling customers to a DR program, specific DR
resources and assets that are associated with customers accounts
and premises will also need to be registered. Figure 4 shows the
actors and use cases involved in administrating DR resources and/or
assets into DR programs. The following use cases deal with the
registration, update, and removal of DR resources and assets
associated with a customer. When updating DR resources, there will
also be potential use cases of DR bidding process, either for
supplying or for buying power. There are also cases where
Distributed Energy Resources will act as DR assets.

Page 12

For Quadrant:
Requesters:
Request No.:
Request Title:
Figure 2. Administrate DR Resources and/or Assets into DR Programs
REQ.17.3.1.4.3.1
Administrate Distribution DR Resource

These activities are used to administer all of the DR Resources
and Assets, including a variety of activities surrounding the
registration of DR Resources and the management of
information surrounding the DR Resources that a Service
Provider may call upon during a DR event. Before a DR
Resource may be called upon, it must be registered with the
Service Provider. The administration of a DR Resource covers
the following requirements:
The need of the Service Provider to identify a DR Resource

for communications purposes;
The need of the Service Provider to establish DR Resource
accounts for accounting purposes;
The need of the Service Provider to collect information from
DR Resources prior to DR events for the purposes of
determining which DR Resources to call upon during a DR
Event; and
Page 13

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.3.2
The need of the Service Provider 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.
Update DR Resource
Description
When the base capacity of a DR Resource changes from when
it was last registered with the DR provider, customer needs to
provide updated information to the DR provider so that such
information can be factored into the consideration for DR event
planning.
Data Requirements
Attribute Name
Resource ID
Resource Type
Service Provider Account
Number
Demand Response Provider
DR Resource Group ID
Description
Identifier assigned to the
Resource
Type of Resource. Examples are:
load reduction (curtailable or
interruptible load), generation,
combination, DG, renewable,
and storage.
Service Provider's (Utility)
account number for the
Resource.
The entity that is responsible for
delivering Demand reductions
from Demand Resources and is
compensated for providing such
Demand Response products.
Grouping of Resources that can

respond to the same DR Signal.
Program Identifier
The identifier of the program
Constraint Type
Type of operational, schedule or
offer constraint
Constraint Interval
The timeframe over which the
constraint type applies.
Constraint Value
Value of the Constraint Type and
Interval
Effective Enrollment Date
Effective Start Date for the
Enrollment
Location
The location of a Resource
defined by one or more of the
following attributes:
Location Attributes
Service Location ID
Identifier assigned to the Service
Location
Page 14

For Quadrant:
Requesters:
Request No.:
Request Title:
Attribute Name
Address1
Address2
City
State/Province
Zip/Postal Code
Country
GPS Coordinates
Weather Station
Zone ID
Zone
Electrical Node ID
Description
Address line 1
Address line 2
City
State or Province two-letter code
Zip or Postal Code
Country
Latitide and longitude
Weather Station code associated
with the Service Location
Identifier assigned to the Zone in
which the Service Location is
located
Name of the Zone in which the
Service Location is located
Identifier assigned to the
Electrical Node at which the
Service Location is connected
Electrical Node Name
Name of the Electrical Node at

which the Service Location is
connected
Electrical Node Type
Type of Electrical Node at which
the Service Location is attached
PNode
Name of the Price Node
associated with the Service
Location
PNode ID
Identifier assigned to the Price
Node associated with the Service
Location
End of Location Attributes
Response Time
Capacity Type
Capacity Type description
Nominal Capacity
The amount of time before an

asset/resource is capable of
meeting its full performance, in
response to a request by a
Service Provider to shed load.
Type of Capacity
Description of the Type of
Capacity
Nominated load

Page 15

For Quadrant:
Requesters:
Request No.:
Request Title:
Attribute Name
Offer Commit Status.
Description
Commitment status of offer
Product-specific commitment
status types included with offer.
Examples include: economic,
emergency, must-run, not
participating, outage run status,
override status, etc.
Also referred to as "opt-in" or
"opt-out" for existing Demand
Response Programs.
Type of Resource
Examples are: load reduction
(curtailable or interruptible load),
generation, combination, DG,
renewable, storage, etc.
Resource Type
Resource Qualification Test

Date
Requalification Test Date
Enrollment End Date
Enrollment Status
Date the Resource demonstrated

its ability to deliver a product or
service
Date the Resource will retest its
ability to deliver a product or
service
Date of Termination of
Enrollment
Status of the Enrollment for the
Resource
Sequence Diagram
REQ.17.3.1.4.3.3
Register DR Resource
Description
A party with ownership, controlling interest, or administrative
responsibilities for a DR Asset or DR Resource that
communicates status-related operational information about the
DR Asset or DR Resource to a Service Provider. For example,
Page 16

For Quadrant:
Requesters:
Request No.:
Request Title:
the owner of a DR Resource or Asset may wish to declare their
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.
Data Requirements
The Data Requirements are the same for Register / Enroll DR
Resource and Update DR Resource.
Sequence Diagram
REQ.17.3.1.4.3.4
Remove DR Resource
Description
When a DR resource is no longer available permanently for DR
purpose, it needs to be removed from the DR program for that
customer so that it will be accounted for DR event planning.
Data Requirements
Attribute Name
Description
Resource ID
Identifier assigned to the Resource that is

removed.
Program Identifier
Enrollment End Date
Date of Termination of Enrollment
Enrollment Status
Status of the Enrollment for the Resource

(Set to REMOVE)

Page 17

For Quadrant:
Requesters:
Request No.:
Request Title:
Sequence Diagram

Page 18

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.4
Administrate DR Asset (Direct)
REQ.17.3.1.4.4.1
Register DR Asset
Description
The DR Asset registration process must capture key identifiers
to enable accurate tracking of DR assets and their capabilities.
A requirement for a System and Market Operator, Load Serving
Entity, Service Provider, or other entity facilitating the
registration process (hereinafter referred to as DR Asset
Administrator) is to track assets. This is done through DR asset
registration and association of physical DR assets to DR
Resources 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.
Data Requirements
Attribute
Name
Asset ID
Program
Identifier
DR Asset
Group ID
Description
Asset
Operator ID
The identifier of the business entity that operates

the DR assets. This is the entity that has physical
control of the asset and control of the capability to
participate in DR Events.
Asset
Operator
Name
The name of the business entity that operates the

DR assets. This is the entity that has physical
control of the asset and control of the capability to
participate in DR Events.
Asset Owner
ID
The Identifier of the business entity that owns the

DR assets (entity that has the right to use or
transfer use of the asset).
Asset Owner
Name
The Name of business entity that owns the DR

assets (entity that has the right to use or transfer
use of the asset).
Location
The location of a Resource defined by one or more

attributes:
Identifier assigned to the Service Location
Service
Location ID
Address1
The unique identifer of the asset

Grouping of Assets that can respond to the same
DR Signal within a DR Resource. (See DR
Resource Specification)
Address line 1
Page 19

For Quadrant:
Requesters:
Request No.:
Request Title:
Attribute
Name
Address2
City
State/Province
Zip/Postal
Code
Country
GPS
Coordinates
Weather
Station
Zone ID
Zone
Electrical
Node ID
Electrical
Node Name
Electrical
Node Type
PNode
PNode ID
Effective
Enrollment
Date
Enrollment
Status
Offer Commit
Status
Description
Address line 2
City
Zip or Postal Code
Country
Weather Station code associated with the Service
Location
Identifier assigned to the Zone in which the
Name of the Zone in which the Service Location is
located
Identifier assigned to the Electrical Node at which
the Service Location is connected
Name of the Electrical Node at which the Service
Location is connected
Type of Electrical Node at which the Service
Location is attached
Name of the Price Node associated with the
Service Location
Identifier assigned to the Price Node associated
Effective Start Date for the Enrollment
(Registration)
Status of the Enrollment for the Asset
Commitment status of offer
Product-specific commitment status types included
with offer. Examples include: economic,
emergency, must-run, not participating, outage run
status, override status, etc.
Also referred to as "opt-in" or "opt-out" for existing
Demand Response Programs.
DR Asset
Physical
Capabilities
Asset Capabilities include Ramp Rates and

Capacity.
Ramp Rate
Value
Ramp Rate associated with the selected Ramp

Rate Type for the selected Ramp Rate Segment
and Ramp Rate Direction
Capacity Type
Type of Capacity
Page 20

For Quadrant:
Requesters:
Request No.:
Request Title:
Attribute
Name
Capacity Type
description
Nominal
Capacity
Asset
Manufacturer
Description
Asset Model
Model Identifier of the Asset assigned by the

Manufacturer
Model Version Identifier assigned by the
Manufacturer.
Date of Manufacture of the Asset
Asset Version
Asset
Manufacture
Date
Asset Type
DR Resources
Description of the Type of Capacity

Nominated load
Manufacturer of the Asset
Type of Asset.
Examples are: load reduction (curtailable or
interruptible load), generation, combination, DG,
renewable, storage, etc.
The identifier of DR resources that the DR Assets
belong to. An Asset can associate with multiple
Resources, but with only one Resource for a DR
Program.
Sequence Diagram

Page 21

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.4.2
Update DR Asset
Description
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 verifying the
authorization to perform the update, each of the considerations
identified in the DR Asset registration step should be evaluated
and utilized, where necessary, during the update of the DR
Asset information. The ability to update DR Asset information
helps to ensure the asset information on record is current and
complete.
Parties that are privy to and rely on the update should be
notified of updates as soon as practicable after they are made.
Additionally, these parties should have access to review and, in
some cases, to approve/disapprove the update(s).
Data Requirements
The Data Requirements are the same for Register / Enroll DR
Asset and Update DR Asset.
Sequence Diagram

Page 22

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.4.3
Remove DR Asset
Description
Removing a DR Asset must take into account any DR
Resource long term commitments in System Operator
programs and contractual obligations with Service Providers or
Load Serving Entities. In addition, applicable regulatory
agency filings and approvals must be considered prior to
removing a DR Asset from a DR program.
Data Requirements
Attribute Name
Description
Asset ID
Program Identifier
Enrollment End Date
Date of Termination of Enrollment
Enrollment Status
Status of the Enrollment for the Asset

(REMOVE)
Sequence Diagram

Page 23

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.5
DR Bidding
Description
Demand Response Bidding occurs after the DR Assets and
Resources that are to comprise the desired bid have been registered
and a bid or an offer 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 entity
operating the DR bidding program (the Bid Receiver) receives bids
from participants (the Bidders). The Bidder may be a Customer
bidding with either an energy retailer (e.g., LSE, ESP), a Service
Provider (e.g., CSP, DRP), or a power marketer (i.e., wholesale
market participant). The Bidder may also be a Service Provider
bidding up to a LSE or power marketer.
Before the start of the bidding process, it is assumed that DR
Resources available for selection are already registered 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 of the bid outcome (e.g., a resource award or
other DR commitment).
Examples of retail DR Bidding programs include:
REQ.17.3.1.4.5.1
Demand Bidding
Capacity Bidding
DR Bid to Supply (Retail Offers)
Description
The Bid Receiver opens the forum/venue for receiving an offer.
(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).
Page 24

For Quadrant:
Requesters:
Request No.:
Request Title:
Each offer will have a clearly specified product or service that
is being bid and the pricing/incentive structure being 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 (or ID) of
the bidder and resource(s) that comprise the bid.
The Bid Receiver reviews bids (offers) 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.
Sequence Diagram
(Note, the Bid in the followign sequence diagram is an offer to
supply)

Page 25

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.5.2
DR Bid to Buy
Description
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 the 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.

Page 26

For Quadrant:
Requesters:
Request No.:
Request Title:
Sequence Diagram

Page 27

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.6
Execute DR Event
The execution of a DR event takes different forms depending on
operational situation and the type of DR programs being executed.
Typically, they fall into one of the following four use cases, see Figure
5:
1.
2.
3.
4.
Advanced DR Notification
Broadcast DR Message (price plus information)
DR dispatch instruction
DR direct load control.
Operational considerations for DR event execution are also

associated with DR programs where direct load control or dispatching
instructions are carried out.
Figure 5. Execute DR Events

Page 28

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.7
Notify DR Event (Retail)
REQ.17.3.1.4.7.1
Advanced Notification for DR (Retail)

Description
This is used by the Service Provider to send the DR Event
notification (i.e., DR signal) to the DR Resource.
The Notify DR Event Message applies to one of three types:
Broadcast DR Message (Price Plus Information)
Dispatch DR Instructions for Objectives (Retail)
DR Direct Load Control (Retail).
The message content specific to each of these types is defined in their
respective sections below.
Data Requirements
The following are the data requirements that are common to
all of the Event Message Types.
Attribute
Name
Program ID
Program
Name
Service
Provider ID
Event ID
Event
Modification
Number
Description
Resource ID
Asset ID
Identifier assigned to the Resource

Program Identifier
Name of the Program
Identifier assigned to the Service Provider
Identifier assigned to the Event

A modification number for the DR event. This is
used to indicate if the DR Event has been
modified by the Utility. Each time it is modified,
this number is incremented.
Area of Event Notice Applicability:
The area affected by the Demand Response Event can be defined
by a Location attribute (point location or area) or is applicable to a
Resource or to an Asset for Direct Load Control.
Location can be identified by any of the following:

Service
Location ID
Address1
Address2
City
State/Provinc
e
Zip/Postal
Identifier assigned to the Service Location

Address line 1
Address line 2
City
Zip or Postal Code
Page 29

For Quadrant:
Requesters:
Request No.:
Request Title:
Attribute
Name
Code
Country
GPS
Coordinates
Weather
Station
Zone ID
Description
Simple Signal
Levels
Used as an alternate and simplified representation

of the DR signal, whether it be price based or a
dispatch. Takes on a small number of finite levels
such as NORMAL, MODERATE, and HIGH,
SPECIAL
Country
Weather Station code associated with the Service

Location
Identifier assigned to the Zone in which the
Zone
Name of the Zone in which the Service Location is
located
Electrical
Identifier assigned to the Electrical Node at which
Node ID
the Service Location is connected
Electrical
Name of the Electrical Node at which the Service
Node Name
Location is connected
Electrical
Type of Electrical Node at which the Service
Node Type
Location is attached
PNode
Name of the Price Node associated with the
Service Location
PNode ID
Identifier assigned to the Price Node associated
The following are other attributes applicable to all DR Event
Messages.
Deployment
Type of Deployment.
Type
Examples are: Advanced (Normal), Immediate,
Audit/Test.

Page 30

For Quadrant:
Requesters:
Request No.:
Request Title:
Attribute
Name
Criticality
Level
Description
This field defines the level of criticality of this
event. The action taken by load control devices
for an event can be solely based on this value, or
combination with other Load Control Event fields
supported by
this device. For example, additional fields such as
Average Load Adjustment Percentage, Duty
Cycle, Cooling Temperature Offset, Heating
Temperature
Offset, Cooling Temperature Set Point or Heating
Temperature Set Point can be used in
combination with the Criticality level.
Criticality Level
0
1
2
3
4
5
6
7
8
9
0x0A to 0x0F
Level Description
Participation
Reserved
Green
Voluntary
1
Voluntary
2
Voluntary
3
Voluntary
4
Voluntary
5
Voluntary
Emergency
Mandatory
Planned Outage
Mandatory
Service Disconnect Mandatory
Utility Defined
Utility Defined
Baseline
Dates of days used to calculate the Energy
Dates
Baseline
Baseline
Exclusion
Dates of days Excluded from the calculation of
Dates
the Energy Baseline
Energy
Baseline
Value
Calculated Energy Baseline
Energy
Baseline
Timestamp
Timestamp of Energy Baseline
Deployment Period (Interval): The deployment period that is
communicated to a Resource or Asset is an interval contained
within the Start or End Time of the Event, but not necessarily for
the entire Event.
Event Start
Time of Start of deployment period for Event
Time
Event End
Time of End of deployment period
Time
Requirement as defined by the ZigBee Smart Energy Profile 2.0 Technical Requirements Document
Page 31

For Quadrant:
Requesters:
Request No.:
Request Title:
Sequence Diagram

Page 32

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.7.2
Update a DR Event (Retail)

Description
This is 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.
Data Requirements
Attribute Name
Description
Event
See the "Advanced Notification for DR" use

case.
Event Modification
Number
This is Modification number of the DR

event. It is used to indicate that the DR
Event has been modified by the Utility or
Service Provider. Each time a DR Event is
modified, this number is incremented.
Modification reason
code
The reason the event was modified.
Sequence Diagram

Page 33

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.7.3
Cancel a DR Event (Retail)

Description
This is used by the Service Provider to notify the DR
Resource that a DR Event is being cancelled. It should only
be executed if a DR Resource has previously received
notification of a DR Event and that event has subsequently
been cancelled.
Data Requirements
Attribute Name
Description
Modification reason
code
The reason the event is being cancelled.
Event Status
Status of the Event
DR Event Identifier
An identifier for the event that is being

cancelled.
Effective date/time
The date and time a cancellation takes

effect.
Sequence Diagram

Page 34

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.7.4
DR Resource Confirmation (Retail)

Description
This is a confirmation message that is sent by a DR Resource
to the Service Provider as a result of receiving a DR Signal
form the Service Provider. It may be used as an
acknowledgement of the receipt of the DR signal, but it may
also contain various information used to signify how the DR
Resource will respond to the DR Signal.
Any changes to the Resource or Asset that may impact
participation or performance for the Event (such as Location
and Load Profile) shall be provided through the Update
Resource or Update Asset Messages.
Data Requirements
Attribute Name
Description
Resource ID
Identifier assigned to the Resource
Asset ID

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.
Exception Conditions
Load Control State
The state of the load, which includes both

commanded states and user settings. This
may include a schedule of future states if a
particular control algorithm for the load
controller is being executed.
Operational
Constraints
Operational Constraints at run time may

differ from those provided at Enrollment,
and will be applicable only to the time
interval of the Event for this Resource or
Asset.
Constraint Type
Type of operational, schedule or offer

constraint
Constraint Interval
The timeframe over which the constraint

type applies.
Constraint Value
Value of the Constraint Type and Interval
Offer Dispatch Status
Dispatch Status of Offer

a.k.a. as Opt-in or Opt-out in existing
programs.

Page 35

For Quadrant:
Requesters:
Request No.:
Request Title:
Sequence Diagram
REQ.17.3.1.4.8
Broadcast DR Message (Price Plus Information)

Description
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 the 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. DR Message
is defined as information about the DR signals that may affect the
demand behaviors of the energy consumers. Obviously, the main
component of the DR Message is the pricing information. However,
there are other attributes of energy being delivered that may be of
interest to energy consumers and could be included in the DR
Message.
Based on the OpenADR discussion, the broadcasting function is
mainly used for volunteer or non-mission critical DR messages.
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 Service Provider sends the DR message to service
providers. In the case of DR pricing, the DR Service Provider
calculates the price per location and communicates the appropriate
price associated with the DR product to service providers.
Page 36

For Quadrant:
Requesters:
Request No.:
Request Title:
Post Condition:
DR Resources received the DR pricing information, and may or may
not act based on the DR agreement or contract.
Data Requirements
Attribute Name
Description
Currency
Economic unit of exchange in which the

total price and price components are stated
(e.g. dollars, euros)
Product Price
Product Price Factor
The sum of all Price Component Values for

a given product (Total Price).
Terms of use attribute of Product Price
Examples: Price absolute, Price relative,
Price multiplier
Unit of Measure
Attribute of Product Identifier
Delivery Time
Time at which the product is available for

physical consumption
Delivery Interval
The duration over which the product is

available for physical consumption
Market Product
Product types include the following: energy,
capacity, regulation, operating reserves
(spinning or non-spin).
Market Product
(Product Type)

Page 37

For Quadrant:
Requesters:
Request No.:
Request Title:
Sequence Diagram
REQ.17.3.1.4.9
Dispatch DR Instructions (Retail)

Description
This interaction is used to dispatch DR Resources. This type of
interaction is used when the Service Provider needs to achieve
specific objectives from the DR Resources during DR events. This
means that specific instructions will be given to the DR Resource with
objectives (e.g. shed 100 kW) 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.

Page 38

For Quadrant:
Requesters:
Request No.:
Request Title:
Data Requirements
Attribute Name
Description
DR Dispatches for DR Objective based messages are of three types.
LOAD LEVEL
LOAD AMOUNT
LOAD PERCENTAGE
Value of the load level to be achieved based on a
For Load Level:
set of enumerated values.
Load Level Value
(e.g. moderate, high, etc)
For Load Amount:
Deployment quantity expressed as an Absolute
Deployment MW
For Load Percentage:
Relative Deployment quantity expressed as %.
Deployment MW
Sequence Diagram
REQ.17.3.1.4.10
DR Direct Load Control (Retail)

Description
This use case covers direct interactions between the DR Service
Provider and a specific DR Asset for the purposes of putting that
asset into a specific load control state (e.g., to 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.
See REQ.17.3.1.4.11.3, DR Execution - Direct Load Control (DLC)
for more details.

Page 39

For Quadrant:
Requesters:
Request No.:
Request Title:
Data Requirements
Attribute Name
Description
Asset ID
(Note: Direct Load Control messages are applicable

only to Assets)
A signal to require the DR resource status to be
Status Check
sent back.
(Only applicable to Direct Load Control)
DR Control Command: The type of DR Direct Load Control Command:
Direct Load Control
e.g. Set Point, Open/Close, Heating Temperature
Type
-offset/setpoint, Cooling Temperature
-offset/setpoint, Load adjustment offset
DR Control Command: Value associated with the Direct Load Control Type.
Direct Load Control
Value
Event Start Time
Time of Start of deployment period for Event
Event End Time
Time of End of deployment period

Duty Cycle : Defines the maximum On state duty
cycle as a percentage of time. Example, if the
value is 80, the device would be in an on state for
80% of the time for the duration of the event.
Range of the value is 0 to 100. A value of 0xFF
indicates the field is not used. (from SEP2.0) Error:
Reference source not found
Duty Cycle
Event Control
Device Class
Event Control options for randomized start or end

times:
1= Randomize Start time, 0=Randomized Start not
Applied
1= Randomize End time, 0=Randomized End not
Applied. (from SEP2.0) Error: Reference source not
found
Enumeration representing the Device Class to
apply the current Load Control Event. Error:
Reference source not found
Sequence Diagram

Page 40

For Quadrant:
Requesters:
Request No.:
Request Title:

Page 41

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.10.1
Monitor DR Event (DR Resource)

Description
This interaction is used to monitor a DR Resource's behavior.
It may be executed as a result of the DR Resource receiving
a DR signal or it may be conducted continuously.
Sequence Diagram
REQ.17.3.1.4.10.2
Monitor DR Event (DR Asset)

Description
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.
Sequence Diagram

Page 42

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.11
DR Event Execution
Demand Response is deployed for economic or a reliability
purposes. At high penetration levels, demand response has to be
integrated with the power supply scheduling process, and it may
impact the distribution grid operation and reliability, and perhaps the
transmission grid operation and reliability. Thus it is important to
include the required considerations for the grid and system level
operations when developing DR Use Cases and DR signal
standards. Such impacts may not be significant at low penetration
levels; however, proper considerations must be given to support
scalability and expandability for future deployments.
Power system operates based on a real-time balancing of supply and
demand. To economically schedule the supply, an accurate load
forecast is needed. Traditionally, load forecast was generated using
the historical consumption patterns, weather forecast and other
similar parameters. With the potential of high-penetration of DR, it
will be necessary to incorporate the planned or forecasted DR levels
into the load forecast. Also, DR capabilities can be used to support
the power system capacity or emergency supply (ancillary service)
needs. Such services require proper scheduling and monitoring
capabilities.
A demand response event may be initiated by a power system
operator in response to a reliability event, e.g., loss of a generating
station causing a lack of supply to meet demand, or an uncontrolled
set of PEVs overloading of a distribution transformer. A demand
response event may also be initiated by utility operational systems
based on economic considerations, e.g., reducing or shifting peak
load at the system level or at specific feeder or facility. Demand
response may also be initiated by a customer in response to a
market pricing signal
Considering that the distribution grid in the US is typically a threephase imbalance circuit, i.e., many customers are on a single-phase
or two-phase of the three-phase system. Thus significant changes in
customer load patters could result in undesirable imbalanced
conditions on a feeder. Also, load pickup following the termination of
a major DR event could possibly cause overloads and other
operational problems, if the load pickup is not properly
scattered/managed.

Page 43

For Quadrant:
Requesters:
Request No.:
Request Title:
The following provides three representative use cases to highlight

some the key interactions. These include:
Dynamic Price-based DR
Notification-based DR
Direct Load Control
REQ.17.3.1.4.11.1
DR Execution Retail Time Pricing (RTP)

Description
Provide real-time or dynamic pricing (RTP) to retail customers
so that customers can vary their demand based on pricing
signals. RTP represents retail electricity rates that vary as a
function of time
Traditionally, retail tariff has based on a fixed or tiered rate
structure with possible considerations of static rates for preestablished time of use (TOU) conditions. Real time or
dynamic pricing (RTP) represent retail electricity rate that
could vary as a function of time and is intended to modify
demand. It requires interval metering for accurate billing
based on time-varying prices. A number of states have
implemented RTP or other dynamic pricing tariffs for large
customers. With a broader deployment of advanced meters,
RTP rates may become more common nation-wide.
The scenario presented here represents a case where a
location-dependent real-time retail pricing for energy is
established based on the Locational Marginal Price (LMP) for
that location. LMP values are typically established by an ISO
(for regions covered by an ISO/RTO) on a day-ahead (hourly
resolution) and real-time basis, typically on a five minute
resolution. For the RTP, it may be appropriate to use the realtime LMP as the basis for computing the retail dynamic tariff.
However, decisions should be made on the time and the
spatial resolution of the RTP. For example, an hourly RTP
averaging the five minute pricing values, or a Critical Peak
Pricing model to reflect the extreme conditions only, may be
adopted. In addition to the energy price, the retail RTP rate
may also include the appropriate uplift charges to cover for
distribution wire/services charges and for the power loss
compensations. Note that the uplift charges are typically
subject to a regulatory review and approval.
Special care must be given to the RTP rate design to ensure
customer acceptance and adaptation. Also grid operational
issues may have to be addressed. For example, during low
Page 44

For Quadrant:
Requesters:
Request No.:
Request Title:
LMP (RTP) periods (e.g., at night), certain distribution circuits
may get over loaded (congested), with customers shifting
consumption, e.g., charging PEVs, to that period. This
improves the overall system economy, but may cause circuit
congestion. To combat this, some have proposed use of
demand charges or an additional incentive payment for load
reduction, a locational incentive to relief congestion.
Sequence Diagram

Page 45

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.11.2
DR Execution Notification Based

Description
Notification-based DR is mostly used for economic purposes
based on a day-ahead or hours or hour-ahead basis.
Notification-based DR may also be used for reliability events
when the system operator expects a contingency or operating
condition (e.g., congestion or planned outage) on the
distribution or the transmission grid that requires a reduction
(or an increase) on the load at a given location.
Considering that the business processes for demand
response have not yet been standardized across the nations,
the following is a representative scenario that captures some
of the interactions between the key stakeholders (actors).
At high penetration levels, the DR operation, especially on a
day-ahead or hour ahead basis, need to be coordinated with
the overall operations and supply scheduling process. As is
shown in the Sequence Diagram below, this may require a
timely update of the locational load forecast and an up-todate nomination of the DR capabilities. This information may
be supplied to the system and/or market operator to be
incorporated in the overall supply and demand scheduling
process.
The DR capabilities are specified by the DR
Provider to the System Operator based on a DR Program, a
price curve, or other nomination protocol. The DR Provider
may also inform the Load Serving Entity (LSE) of the
locational available DR capabilities.
The notification-based DR dispatch process is typically
initiated by the System or Market Operator; the process may
also be initiated by an LSE or UDO. It is also possible that
the DR Provider be the initiator of the DR process based on a
market opportunity (economic operation) or based on a preestablished program.
At high DR penetration levels, it is expected that the DR
provider will need to clear the DR schedule with the
Distribution Grid Operator, the UDO. This is to insure that the
high penetration DR has no adverse impact on the distribution
grid reliability and power quality, e.g., cause of excessive
imbalances, voltage violation, or an overload during load
pickup period. The UDO, in a timely fashion, will inform the
DR Provider, if the schedule is cleared or requires an
adjustment. Please note that if the DR deployed by a utility
company that includes both LSE and UDO functions, such
coordination is performed within the companys operational
Page 46

For Quadrant:
Requesters:
Request No.:
Request Title:
systems (e.g., DRMS, DMS, etc.), or it can be an integral part
of the DR scheduling application.
Following the clearing the DR schedule, notifications are sent
to customers for DR operation. Under this scenario, the
Market Operator and the LSE are also informed of the final
DR schedule.
Sequence Diagram

Page 47

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.11.3
DR Execution Direct Load Control (DLC)

Description
Direct-Load Control is typically used for reliability-based
events such as contingency and emergency support, supply
of balancing energy or other ancillary service. Many of these
programs require quick response time, e.g., five minutes or
faster, that is practically only possible through a DLC
capability. Direct-Load Control may also be used for economic
operations, e.g., water heater programs to reduce or shift
peak load.
Considering that the business processes for demand
response have not yet been standardized across the nations,
the following is a representative DLC scenario that captures
the interactions between the key stakeholders (actors).
Direct Load Control is typically called for by a system
operator, a transmission or distribution operator. It could be
also issued by a Market Operator based on an ancillary
service DR award, or by an LSE or DRP for an economic
purpose. At high penetration levels, DLC operation needs to
be coordinated with the distribution grid operator, the UDO.
As is shown in the sequence diagram below, the customer DR
capabilities
are
aggregated
by
location
and
specified/nominated to the Distribution Grid Operator, Load
Serving Entity, and/or to the System/Market Operator.
In
addition to location, the capabilities may also be aggregated
by the DR response time, e.g., four seconds, five minutes, 30
minutes, etc.
The DLC Dispatch process is typically initiated by the
Transmission or Distribution Operator. The process may also
be initiated by the Market Operator or the LSE. The actual
control of the DR resources may be done by the DR provider
based on the dispatch signal received.
At high DR penetration levels, it is expected that the DLC
activation schedule to be coordinated with the Distribution
Grid Operator, the UDO. This is to insure that there are no
adverse impact on the distribution grid reliability and power
quality, e.g., voltage violation, excessive phase imbalances,
or an overload during load pickup period. If the DLC
deployed by a utility company such coordination can be
accomplished within the companys DR and distribution
management systems, or performed as an integral part of the
DR control functions.
Page 48

For Quadrant:
Requesters:
Request No.:
Request Title:
For a fast DR, e.g., provision of ancillary services, a
telemetry capability is required to enable the real-time
monitoring of the resource condition and its response to the
DR control signal.
Sequence Diagram
REQ.17.3.1.4.12
Operational Coordination
Due to the existing differences in the regional retail energy market
regulations, wholesale market structure and protocols, and supply
and demand conditions, currently there are regional differences in
business practices and processes governing demand response. As
a result, operational coordination requirements for demand response
somewhat vary from region to region, depending on the available
retail tariff, retail market structure, available wholesale market for DR
and the market mechanics.
The following table summarizes the major roles and responsibilities
of the key stakeholders with respect to demand response operation.
As can be seen in this table, a significant level of stakeholder
coordination is required for an end-to-end DR operation spanning
from the wholesale markets to the end-use customers.
Page 49

For Quadrant:
Requesters:
Request No.:
Request Title:
Stake Holder
Key Responsibilities
Wholesale Market
Operator
Establish, administer, and operate wholesale

demand response programs and markets;
Determine and publish locational prices for

wholesale demand response products;
Improve energy market efficiencies (economics)

by integrating demand response products and
capabilities;
Monitor compliance to wholesale DR instructions

and financially settle with the participating
stakeholders.
Monitor and maintain transmission grid

reliability, and call upon wholesale demand-side
(demand response) capabilities to address
contingency/emergency conditions;
Dispatch demand-side capabilities to balance

supply and demand, e.g., mitigating impact of
variable generation (e.g., wind).
In regions with no organized wholesale energy

market,
economically
dispatch
available
generation and demand resources including
demand response to optimize supply economics.
Transmission Grid /
System Operator Balancing Authority

Page 50

For Quadrant:
Requesters:
Request No.:
Request Title:
Stake Holder
Distribution Grid
Operator Utility
Distribution
Company
Monitor and maintain the distribution grid

reliability and the quality of power supply (e.g.,
voltage levels). Call upon DR to mitigate the
distribution
contingencies
and
reliability
concerns.
Review and approve the integration of

distributed energy resources with the distribution
grid.
Assess the operational impact of distributed

resources and demand response (DR/DER) on
power quality and reliability of the distribution
grid, approve high-penetration DR schedules
(especially cold-load pickup operation).
Coordinate with the respective Load Serving

Entity and Energy Service Providers for the
assessment of distribution service and loss
compensation charges to retail customers.
Forecast load and economically schedule supply

to meet demand at all times.
Incorporate
demand response capabilities to improve load
factor, reducing/shifting peak load.
Establish and obtain regulatory approval for a

fair and unbiased retail tariff for all customer
classes. For real-time dynamic pricing (RTP)
tariff,
apply
distribution
service,
loss
compensation and other uplifts to the wholesale
locational prices.
Establish and administer demand response and

distributed resource management programs
including DR tariff.
Meet regional requirements for Renewable

Portfolio Standards compliance for power
delivery.
Aggregate and schedule DR capabilities in

wholesale markets, manage DR programs.
Manage customer metering and billing process.
Load Serving Entity

Page 51

For Quadrant:
Requesters:
Request No.:
Request Title:
Stake Holder
Power Marketer
Forecast load and economically schedule supply

to meet demand at all times.
Incorporate
demand response capabilities to improve load
factor, reducing/shifting peak load.
Establish and obtain regulatory approval for a

fair and unbiased retail tariff for all customer
classes. For real-time dynamic pricing (RTP)
tariff,
apply
distribution
service,
loss
compensation and other uplifts to the wholesale
locational prices.
Operate a wholesale and/or retail demand

response programs with wholesale and/or retail
customers.
Operate only in regions with competitive retail

market
Be an alternative supplier of electric power to

end-use customers by offering competitive
products, services and prices.
Forecast aggregated load of the

customers by location as required.
Coordinate the power supply with the respective

LSE and UDO.
Support demand response programs (DR/DER)

for enrolled customers.
Aggregate
demand
and
demand-side
capabilities; schedule the aggregated load and
DR capabilities in wholesale markets.
Provide for DR telemetry and other monitoring

requirements, on a resource or aggregated
basis.
Apply the necessary uplifts (e.g., distribution

service and loss compensation charges) to the
wholesale locational prices.
Meet regional requirements for Renewable

Portfolio Standards compliance for power
delivery.
Bill and settle with customers for energy supply

and DR operation.
Energy Service
Provider
enrolled

Page 52

For Quadrant:
Requesters:
Request No.:
Request Title:
Stake Holder
Demand Response
Provider
Offer competitive demand response services to

the end-use customers.
Design and manage DR programs, establish

pricing structure and signals for DR operation
Aggregate
demand
and
demand-side
capabilities;
and
offer/schedule
these
capabilities with the respective LSE or the
wholesale market.
Provide for DR telemetry and other monitoring

requirements, on a resource or aggregated
basis.
Bill and settle with customers for energy supply

and DR operation.
Subscribe to a DR program, and update DR

availability and capability information as
appropriate
Maintain DR resources, data communications,

telemetry, metering and control devices as
required.
Respond to pricing signals, DR notifications, or

control signals as appropriate.
Electricity Customer

Page 53

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.13
Post DR Event Management

Post DR event management mainly concerns with the reconciliation
of the actual consumption of energy within the duration of a DR
event with the expected behavior so that proper financial reward or
penalties could be carried out. The NAESB M&V standard for DR
defines the requirements for most of the post event management.
The following use cases describe post DR event management for
three different market types.

Page 54

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.13.1
Post DR Event M&V / Settlement (No Open Retail)

Description
After DR Event has been completed, then Measurement and
Verification (M&V) can confirm whether action has been taken
or to measure the impact of the response. After the M&V,
then the Financial Settlement is calculated and sent to the
Electricity Customer4. This Use Case covers the scenarios
with no Open Retail Markets.
Sequence Diagram
In wholesale markets, the settlement for a DR Event is between the System Operator and Market
Participant and possibly between the Market Participant and the Electricity Customer.
Page 55
4

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17.3.1.4.13.2
Post DR Event M&V / Settlement (Open Retail)

Description
After DR Event has been completed, Measurement and
Verification (M&V) can confirm action has been taken or to
measure the impact of the response. After the M&V, the
Financial Settlement is calculated and sent to the Electricity
Customer. This Use Case covers the scenarios with Open
Retail Markets.
Sequence Diagram

Page 56

For Quadrant:
Requesters:
Request No.:
Request Title:
REQ.17-A Appendix A Entity-Relationship Model

The following terms and definitions correspond to a set of actor and objects within
the overall information model for demand response. Figure 1A contains a data
model used to illustrate the entity-relationships within the model.
Abbreviations/Acronyms correspond to the IDs shown in the figure.
Proper (and Improper) Usage of the Entity-Relationship Model.
The entityrelationship model is used to show cardinality among objects in the model, for
example every Resource belongs to one and only one Service Provider and a
PremiseService Location contains one or more End DevicesService Delivery Points.
The entity-relationship model does not provide use case information; actors are
objects in the model and do not act in the model. The entity-relationship model
does not imply process. For example, a Service Provider is associated with many
Resources; however the enrollment of those Resources may be managed by a
System Operators or a Utility Distribution Operator. Both use cases and process
maps are separate components of the Model Business Practices.
Reading Crows Foot Notation. Objects in the model which share a relationship
are connected with a cardinality line. Each end of the cardinality line contains a
Crows Foot notation, as documents in the legend of the figure. The four notations
utilized are exactly-one, one-or-more, zero-or-one, and zero-or-more. The
cardinality line is bi-directional; meaning it can be read in two directions. For
example: a PremiseService Location is related to one-or-more End DevicesService
Delivery Points (reading top to bottom) and every End DevicesService Delivery Point
is related to exactly-one PremiseService Location (reading bottom to top).
Optional Objects. The entity-relationship model is designed to support multiple
business models and not every business model will require all objects to function.
Therefore, all objects in the model are considered optional. For example, a Utility
Distribution Operator may design a Demand Response program which requires the
definition of Resources and Service Locations, but does not require Asset Groups
and Assets.
Optional Objects. The entity-relationship model is designed to support multiple
business models and not every business model will require all objects to function.
Therefore, all objects in the model are considered optional. For example, a Utility
Distribution Operator may design a Demand Response program which requires the
definition of Resources and Service Locations, but does not require Asset Groups
and Assets.
Applicability to Retail and Wholesale. The entity-relationship model is applicable
to both wholesale and retail. When using the model for wholesale, the applicable
business entities are 2.1 (System Operator) and 2.3 (Market Participant), while in
Page 57

For Quadrant:
Requesters:
Request No.:
Request Title:
retail markets, the parallel business entities are 2.3 (Utility Distribution Operator) and
2.4 (Utility Customers). Other than the swapping of the two pairs of terms, the
models are identical, including the names of and relationships among objects.
Figure 1A. Entity-Relationship Model for Smart Grid Use Cases
l a
. 1
i n
i t
i e
i c
i d
l e
j e
. S
i n
i c
i l i t
i t
i c
i p
i g
. 2
i c
i p
i s
i c
i o
i t
l e
. 4
t
5
. 6
. 2
i s
i s
i b
i o
i o
. 5
S
i c
i p
i c
i v
i l i t
i t
i d
i n
i b
i t
i e
i l i z
i l
i l i t
i n
)
4
S
D
(
p
,
N
D
1
. 5
. 4
P
. 4
t
3
. 2
l i n
. 3
i r
. 2
l i a
l l m
j e
. 3
. 1
3
R
1
5
(
(
m
S
. 1
3
i p
i s
i o
i c
. 3
i o
y
p
l a
. 1
i n
l a
i l i t
. 2
(
E
l y
i t
i n
i c
i t
i n
l i v
. 1
)
M
. 5
6
P
4
O

Page 58

For Quadrant:
Requesters:
Request No.:
Request Title:
4. Supporting Documentation
a. Description of Request:
REQ Annual Plan Item 9(c) Develop Requirements and Use Cases for PAP 09
Demand Response/Distributed Energy Resources
b. Description of Recommendation:
This recommendation provides the data requirements related to the use cases
developed as part of the phase one effort
c. Business Purpose:
This recommendation has been developed in response to a request from NIST to
provide use cases and requirements germane to the development of standard DR
and DER signals.
d. Commentary/Rationale of Subcommittee(s)/Task Force(s):
NAESB Smart Grid Standards Subcommittee Meeting Notes/Documents:
March 11, 2010 Meeting Notes To be posted
April 1, 2010 Meeting Notes To be posted
May 13, 2010 Meeting Notes To be posted
May 20, 2010 Meeting Notes To be posted
June 10, 2010 Meeting Notes To be posted
June 17, 2010 Meeting Notes

http://www.naesb.org/pdf4/smart_grid_ssd061710notes.doc
July 1, 2010 Meeting Notes To be posted
July 13-14, 2010 Meeting Notes To be posted
July 22, 2010 Meeting Notes To be posted
August 5, 2010 Meeting Notes



Page 59

For Quadrant:
Requesters:
Request No.:
Request Title:
September 9, 2010 Meeting Notes

September 16, 2010 Meeting Notes

September 23, 2010 Meeting Notes To be posted

Page 60

Recommended Standards

Uploaded by

Copyright:

Available Formats

Recommended Standards

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Recommended Standards

Uploaded by

Copyright:

Available Formats

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

EFFECT OF EC VOTE TO ACCEPT

Change to Existing Practice

Draft Recommendation October 14, 2010

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

Draft Recommendation October 14, 2010

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

Model Business Practices

Specifications for Retail Standard Demand Response Signals

Any work (artifacts)

The use of common

Draft Recommendation October 14, 2010

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

The integrity of the

Draft Recommendation October 14, 2010

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

Cover All Market

Include: this indicates additional scenarios

The second is the sequence diagram, which shows the information

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

Designated Dispatch Entity

Designated Dispatch Entity

End Device (ED)

Federal Regulator (FR)

Load Serving Entity

Load Serving Entity (LSE)

Local Authority (LA)

Market Participant (MP)

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

Metering Authority (MA)

Reliability Authority (RA)

Scheduling Entity (SE)

Service Provider (SP)

State Regulator (SR)

Draft Recommendation October 14, 2010

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

Utility Customer (UC)

Utility Distribution Operator

Use Case Overview

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

Figure 1. Retail Market DR Use Case Overview

Draft Recommendation October 14, 2010

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

Specific Use Cases

Administrate Customer for DR

Draft Recommendation October 14, 2010

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

Figure 2. Administrate DR Resources and/or Assets into DR Programs

Administrate Distribution DR Resource

The need of the Service Provider to identify a DR Resource

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

The need of the Service Provider to collect information from

Grouping of Resources that can

RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE

Electrical Node Name

Name of the Electrical Node at

The amount of time before an

Draft Recommendation October 14, 2010