1. Developing IEC and CIM Compliant Functional Requirements and Use Cases for a Demand Response Management System (DRMS)
Commercial
Loads
Power Supply Sources
Transmission
Assets
Residential
Loads
Distribution
Assets
Industrial
Loads
Joint UCAIug/DNP Users Groups Meeting
February 2, 2009
UCA AMI ENT DR Use Case Team
Kay Stefferud, Lockheed Martin,
Jerry Melcher, EnerNex ,
Our experience developing the Demand Response

2. AMI ENT Demand Response Use Case Team
Jeff Benson, AEP
Trey Fleming, SAIC
Greg Hinchman, Lockheed Martin
Doug Houseman, Capgemini
Alex Levinson, Lockheed Martin
Wayne Longcore, Consumers Energy
Randy Lowe, AEP
John Mani, Converge
Stuart McCafferty, EnerNex consultant
Jerry Melcher, EnerNex consultant
Terry Mohn, SDG&E
Phil Montell, AEP
Greg Robinson, Xtensible Solutions
Craig Rodine, GridNet
Meir Shargal, Capgemini
Kay Stefferud, Lockheed Martin
Eva Thomas, Corporate Systems Engineering
Bon Truong, SDG&E
Mark van den Broek, Lockheed Martin
Xiaofeng Wang, GE Energy
AMI ENT Task Force
Use Case Team
SRS Team
Service Definition Team
Team Leader:  Terry Mohn
Website :
Membership open to all interested parties Contact

3. Overview
Purpose: Develop use cases and functional requirements for Demand Response Systems
Focus on requirements for California State PUC filing and CEC Demand Response Analysis and Control (DRAC).
Attempt to generalize this work across the industry
Group has been meeting weekly since late Oct 2008; two face to face meetings in November and December respectively.
Timeframe
October Kickoff Knoxville AMI ENT Task Force Meeting
October Use case development begins
February DR Use case development complete
March DR Functional requirements complete
Identification of requirements.
California-specific vs. international markets, integrating with the IEC CIM model, and

4. Approach On-going review of existing Public Domain Use Case Models
Many groups developing DR Use Cases
Collaboration advancing slowly but steadily
SCE Use Cases copyrighted and readily available
Developed Business Process Models
Defined Users (actors)
Used AMI ENT sanctioned Enterprise Architect to tool
Compatible with existing and future AMI ENT use case and requirements
AMI System Security Requirements and Guidelines 1.0 incorporated
IEC61850 CIM compliant
Working towards one consistent use case model
Gradually achieving consensus among participants as reflected in the following slides

5. Four Types of Demand Resource Services
(ref: NAESB//NERC)

6. Primary Use Case
Existing SCE + UCA use cases shown here

7. Snapshot of Requirement Document
6.2.4 Manage DR Program
Snapshot of Requirement Document
Association of Pricing and Direct Load Signals to DR Programs
The DR solution shall be able to associate pricing and direct load signals to appropriate DR programs.
DR Program Creation and Maintenance
The DR solution shall provide the ability for the Program Manager to create and maintain DR programs.
DR Program Enrollment and Dis-enrollment
The DR solution shall provide the ability to enroll and dis-enroll customers from DR programs.

8. Lessons Learned – Use Case Collaboration
Incorporation of existing DR Use Cases
Many use cases
Merging existing, not re-inventing use cases
Framework for merging is work in progress
SCE cases copyrighted but readily available
IntelliGrid Architecture project Use Case link on AMI ENT site
Some DR Use Cases difficult to acquire
Collaboration with other DR use Case groups advancing slowly
Zigbee/HAN, Joint IOU HAN, CALISO DR
Utility Use Cases (AEP, SCE, Consumers, etc.)
Suggestions on how best to unite efforts

9. Lessons Learned – IEC 61850
IEC61850 has no clear representation for Demand Response
DR has no high level traceability to CIM
Added extension domain model (next chart)
Have approached IEC standard experts, but need additional networking
2+ year time frame
DR extensions integration
Roadmap and timeline needed
Demand Response specific IEC additions
Collaboration interface needs to be established
Erich Gunther, EnerNex leading IEC interface effort

11. Lessons Learned – CA vs. International
AMI ENT goal: International IEC standard
Team members: Two drivers DRACS Study & CA IOU DR programs
Need to consider how to incorporate DR variants
Geographic
Utility (Public, private, government, coops)
Utilities manage different segments of electric grid
DR participants (ISOs, aggregators, PUCs, etc.)
Despite multiple variants, robust model key competitive advantage
Approach: General EA model tailorable for any specific application
High level EA model
Specific systems start with base model
Store all models on UCA site

12. Lessons Learned – Task Specific vs. Complete set of Use Cases
Groups focused on near term specific outputs
AMI ENT goal is complete set of use cases
Plan is to place use cases in UCA site
Need plan to harness resources
Voluntary participation working
Utilities reluctant to publish use cases
Third party sponsored use cases generally available
Outreach to sponsored groups would yield additional use cases
Multi-year use case development roadmap advisable

13. Next Steps Requirements document Increased collaboration NERC AMI
Liaisons to other DR Use Case teams
NERC AMI

14. Backup Slides

16. DR Business Process Model

17. Actors

18. Use Case Model Here’s how the use cases are organized
uc Use Case Model
Actors
The Use Case model is a catalogue of system
Actors are the users of the system being
functionality described using UML Use Cases. Each Use
+ Aggregator
modeled. Each Actor will have a well-
Case represents a single, repeatable interaction that a
+ Billing Agent
defined role, and in the context of that
user or "actor" experiences when using the system.
+ Customer
role have useful interactions with the
+ Customer Commercial
system.
A Use Case typically includes one or more "scenarios"
which describe the interactions that go on between the
+ Customer Industrial
A person may perform the role of more
Actor and the System, and documents the results and
+ Customer Residential
than one Actor, although they will only
exceptions that occur from the user's perspective.
+ Distributor
assume one role during one use case
+ Energy Service Provider
interaction.
Use Cases may include other Use Cases as part of a
+ ISO
larger pattern of interaction and may also be extended
An Actor role may be performed by a
by other use cases to handle exceptional conditions
+ Large C/I Customer and Co-Generator
non-human system, such as another
+ Metering Agent
computer program.
+ Settlement Agent
+ Small-Scale Merchant Generator
+ Mission Statement
+ Entity1
Primary Use Cases
+ Actor1
This package contains use cases which
+ ISO
define how an Actor will interact with
+ Manage Demand for Mainenance Purpose
the proposed system.
+ Manage Demand in respond to Pricing Signal
Each interaction may be specified
+ Curtail Demand
using scenarios, sequence diagrams,
+ Decrease Supply
communication diagrams and other
+ Demand Bid
dynamic diagrams or textual
+ Demand Response
descriptions which together how the
system when viewed as a "black-box"
+ Direct Load Control
interacts with a user.
+ Dynamic Pricing
+ Increase Supply
+ Manage Aggregator
Here’s how the use cases are organized
+ Manage Demand
+ Manage Demand for Economic Effect
+ Manage Demand Side Program
+ Manage Demand through Direct Load Control
+ Manage DR Customer
+ Manage DR Program
+ Manage Load
+ Manage Market Operations
+ Manage Supplier
+ Manage Supplier
+ Manage Supply
+ Manage Supply through Direct Control
+ Manage Supply through Price Signal
+ Provision Demand Response Equipment
+ Provision Demand Response Equipment
+ Trading

19. Business Process Model
analysis Business Process Model
Business Context
The Business Context package contains
The Business Process Model describes both the
+ Strategies
models of all involved stakeholders,
behavior and the information flows within an
mission statements, business goals and
organization or system.
+ Stakeholders
physical structure of the business "as-is".
+ Topology
As a model of business activity, it captures the
significant events, inputs, resources, processing and
outputs associated with relevant business processes.
Business Objects
+ datastore
The Business Objects package contains a
+ report1
domain model of all objects of interest
and their respective data.
Business Workflows
The Workflows package documents
+ Process
business processes, drawing on
+ Event1
stakeholders, structures and objects
+ Input
defined in the Context and Object
+ Result
packages showing how these work
together to provide fundamental
business activities.