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

Table of Contents

Use Case Document	1
1	Introduction	4
1.1	Purpose of Document	4
1.2	Glossary	4
2	Application Overview	4
2.1	Define the Scope	4
2.2	Context	4
2.3	Technical Environment	4
Use Cases	5
3	Model	5
3.1	NAESB Demand Response Use Cases for NIST Smart Grid	5
3.1.1	Actors	6
DR Aggregator	7
DR Asset	7
DR Resource	7
Demand Response Program	8
Distributed Energy Resource (DER)	8
Distribution Company	8
Electricity Consumer	8
Load Serving Entity (LSE)	9
System and Market Operator	9
3.1.2	Primary Use Cases	9
Advanced Notification of DR Event	10
Sequence Diagram	12
DR Asset or Resource	12
DR Program Participant	12
Asset or Resource Declaration	13
Interaction	13
Sequence Diagram	14
Asset or Resource Registration	14
Interaction	16
Sequence Diagram	16
Asset/Resource Owner	17
Controlling Entity	17
Broadcast Locational Wholesale Price	18
Sequence Diagram	19
Recipient	20
Cancel Advance Notification of DR Event	20
Sequence Diagram	21
DR Asset or Resource	22
DR Program Participant	22
Dispatch Instruction to DR Asset or Resource	22
Sequence Diagram	23
DR Asset or DR Resource	24
DR Program Participant	24

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

 

3.1.1	Actors

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.

Figure 2: Actors

 

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 Resource
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).

 

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 (DER)
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).

 

Electricity Consumer
Any entity that consumes electricity.

 

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

 

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	Primary Use Cases

Figure 3: Use Cases for DR Programs

 

Advanced Notification of DR Event
Description:

One or more communications  to DR Program Participants 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.

Element Name	Description	Type	
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

DR Asset or Resource

 

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

  

Asset or Resource Declaration
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.

Element Name	Description	Type	
Asset-ID	Uniquely identifies a DR Asset	Functional	
Effective-Start-Date	The date and time when the declared capabilities will be in effect.	Functional	
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. 
	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	
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. 	Functional	
Resource-ID	Uniquely identifies a DR Resource	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	

Interaction

Sequence Diagram

CANNOT-BE-IN-PAST
Start date cannot be in the past. 
Asset or Resource Registration
Description:

The capabilities, characteristics and location of each asset or resource must be made known to the controlling entities that may dispatch the asset/resource as part of a demand response program. 

Element Name	Description	Type	
Asset ID	Uniquely identifies a DR Asset	Functional	
Available-Capacity	The total amount of power (negawatts) available from the asset/resource. Expressed in interger format representing the amount of kilowatts available.	Functional	
Effective-Start-Date-Time	The start date and time which an asset/resource is available	Functional	
Location	An identifier to indicate the location of the asset/resource	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	
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.	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.		
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.	Functional	
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.	Functional	
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
	Functional	
Resource ID	Uniquely identifies a DR Resource	Functional	
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	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	

Interaction

Sequence Diagram

Asset/Resource Owner
May be an Electricity Consumer, DR Aggregator, LSE, Distribution Company

 

Controlling Entity
May be a System Operator, LSE, DR Aggragator, Distribution Company, etc.

  

MIX-MAX-DURATION-CONSTRAINT
The Minimum-duration value MUST be less than the Maximum-duration value 
Broadcast Locational Wholesale Price
Description:

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

Element Name	Description	Type	
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

Recipient
A person, system or device capable of receiving a price signal sent by a Market Operator.

A recipient may be a DR Aggregator, Distribution Company or Load Serving Entity or other interested parties.

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. 
Cancel Advance Notification of DR Event
Description:

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

Element Name	Description	Type	
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

DR Asset or Resource

 

DR Program Participant
May be a DR Aggregator, LSE, Distribution Company or Electricity Consumer

 

MUST-REFER-TO-ACTIVE-ADVANCED-NOTIFICATION
Can only be issued for an active Advacned Notification of DR event. 
Dispatch Instruction to DR Asset or Resource
Description:

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

Element Name	Description	Type	
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

DR Asset or DR Resource

 

DR Program Participant
May be a DR Aggregator, LSE, Distribution Company or Electricity Consumer