Developing IEC61850 and CIM Compliant Functional Requirements and

Use Cases for a Demand Response Management System (DRMS)

Joint UCAIug/DNP Users Groups MeetingFebruary 2, 2009

UCA AMI ENT DR Use Case Team Kay Stefferud, Lockheed Martin, kay.stefferud@lmco.com

Jerry Melcher, EnerNex , jerry.melcher@enernex.com

Power Supply SourcesTransmissionAssets

DistributionAssets

ResidentialLoads

IndustrialLoads

CommercialLoads

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

Team Leader: Terry Mohn (MMohn@Semprautilities.com)

Website : http://osgug.ucaiug.org/utilityami/default.aspx

Membership open to all interested partiesContact Kay.Stefferud@lmco.com

AMI ENT Task Force

Use Case Team SRS Team Service Definition Team

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 2008 Kickoff Knoxville AMI ENT Task Force Meeting– October 2008 Use case development begins– February 2009 DR Use case development complete– March 2009 DR Functional requirements complete

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

Four Types of Demand Resource Services

Energy Service

• Compensated Solely for Demand Reduction Performance

Capacity Service

• Obligated Capacity Availability over Defined Time Period

Reserve Service

• Obligated Capacity based on Reserve Requirements for Reliability

Regulation Service

• Responds to Real Time Signals to Increase or Decrease Load

• Subject to Dispatch Continuously During Commitment Periods

(ref: NAESB//NERC)

Primary Use Caseuc Primary Use Cases

Manage Demand

Prov ision Demand Response Equipment

Manage DR Customer

Distributred Energy Management

Manage Supply

Manage DR Program

Manage Demand for Economic Effect

Manage Demand through Direct Load

Control

Manage Supply through Price Signal

Manage Supply through Direct

Control

Manage Supplier

ISO

Customer

Distributor

Prov ision Demand Response Equipment

Small-Scale Merchant Generator

Large C/I Customer and Co-Generator

Demand Response Prov ider

Add DR Dev ice Remov e DR Dev ice

Manage Demand for Mainenance Purpose

Manage Demand in respond to Pricing

Signal

«include»

«precedes»«precedes»

«include»

«precedes»

«precedes»

«include»«include»

«precedes»

«include»

«include»

«include»

«include» «include»

«include»

«precedes»

req Manage DR ProgramDR Program Creation & Maintenance

DR Program Enrollment & Dis-enrollment

Association of Pricing & Direct Load Signals to DR Programs

The arrow lines mean dependency.

Snapshot of Requirement Document

Association of Pricing and Direct Load Signals to DR ProgramsThe DR solution shall be able to associate pricing and direct load signals to appropriate DR programs.

DR Program Creation and MaintenanceThe DR solution shall provide the ability for the Program Manager to create and maintain DR programs.

DR Program Enrollment and Dis-enrollmentThe DR solution shall provide the ability to enroll and dis-enroll

customers from DR programs.

6.2.4 Manage DR Program

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

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

class DR Extension Domain Model

ProgramStakeholderRegulator

Customer

Residential Commercial Industrial

RateStructure Location

DRTransaction

BaselineUsage

ActualUsage

Bill

Settlement

DRDeliv eryAction

SupplierResourceAv ailabilityCurv eDomain Model of entities involved in the "Distribution Operator or Supplier curtails/l imits customer load for grid management" scenario

Market

Prov isionedLoadControlEquipment

causes a

approved by

determined by

has a

has a offered at

triggers a

monitors

issues

is credited, debited or penalized

involves a

used by

participtes in

constrains

has a

involves

«generalization»«generalization»

involved in

is located at

«generalization»

provisioned

involved in

has a

participates in

is billed or credited

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

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

Next Steps

• Requirements document• Increased collaboration

– Liaisons to other DR Use Case teams• NERC AMI

Backup Slides

object Business Functions

IEC-61968 IRM

Distribution Mamagement

External to Distribution Management

Electric Distribution Network Planning, Construction, Maintenance, and Ops

Generation and Transmission Management, ERP, Supply Chain, and

General Corporate Serv ices

NO- Network Ops

AM - Records and Asset Management

OP - Operational Planning and Optimization

MC - Maintenance and Construction

EMS - Energy Management and

Trading

RET- Retail

SC - Supply Chain and Logistics

NE - Network Extension Planning

CS - Customer Support

MR - Meter Reading and

Control

ACT - Customer Account

Management

FIN - Financial

PRM - Premises

HR - Human Resources

class Business Process Model

Manage Energy Deliv ery

Customer

Energy Shortage/Congestion/Equipment

Failure

«goal»Maintain Reliability of

the Grid

Load Control Transaction

ISO

(from Actors)

Supply Profile

Compliance

«uses»«load»

«signal» «supply»

DR Business Process Model

Actors

uc Actors

Metering Agent

Settlement Agent

Billing Agent

ISO Distributor

Small-Scale Merchant Generator

Large C/I Customer and Co-Generator

Demand Response Prov ider

Customer Residential Customer Commercial Customer Industrial

Customer

A system that collects detailed information about customer loads and customer response patterns. It also maintains information regarding the number of times a customer has complied in a given time period vs the compliance requirements of the tariff applicable to that customer.

This information is brought together for the user so that the user can see what probable load is available to be curtailedin total and at various points in the network.

The system will also receive and process requests for curtailment and will balance the requests across subscribers based on load, and how recently they have been curtailed.

Demand Response ManagementSystem (DRMS)

Regulator

«role»

«role» «role»

«generalization»

«generalization»

«generalization»

«role»

«role»

«role»

«role»

«role»

«role»

«role»

Use Case Model

uc Use Case Model

The Use Case model is a catalogue of system functionality described using UML Use Cases. Each UseCase represents a single, repeatable interaction that a user or "actor" experiences when using the system.

A Use Case typically includes one or more "scenarios" which describe the interactions that go on between the Actor and the System, and documents the results and exceptions that occur from the user's perspective.

Use Cases may include other Use Cases as part of a larger pattern of interaction and may also be extended by other use cases to handle exceptional conditions

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.

Actors

+ Aggregator

+ Billing Agent

+ Customer

+ Customer Commercial

+ Customer Industrial

+ Customer Residential

+ Distributor

+ Energy Service Provider

+ ISO

+ Large C/I Customer and Co-Generator

+ Metering Agent

+ Settlement Agent

+ Small-Scale Merchant Generator

+ Mission Statement

+ Entity1

Primary Use Cases

+ Actor1

+ ISO

+ Manage Demand for Mainenance Purpose

+ Manage Demand in respond to Pricing Signal

+ Curtail Demand

+ Decrease Supply

+ Demand Bid

+ Demand Response

+ Direct Load Control

+ Dynamic Pricing

+ Increase Supply

+ Manage Aggregator

+ 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

This package contains use cases which define how an Actor will interact with the proposed system.

Each interaction may be specified using scenarios, sequence diagrams, communication diagrams and other dynamic diagrams or textual descriptions which together how the system when viewed as a "black-box" interacts with a user.

Business Process Model

analysis Business Process Model

The Business Process Model describes both the behavior and the information flows within an

organization or system.

As a model of business activity, it captures the significant events, inputs, resources, processing and outputs associated with relevant business processes.

Business Context

+ Strategies

+ Stakeholders

+ Topology

Business Objects

+ datastore

+ report1

Business Workflows

+ Process

+ Event1

+ Input

+ Result

The Business Context package contains models of all involved stakeholders, mission statements, business goals and physical structure of the business "as-is".

The Business Objects package contains adomain model of all objects of interest and their respective data.

The Workflows package documents business processes, drawing on stakeholders, structures and objects defined in the Context and Object packages showing how these work together to provide fundamental business activities.