View
213
Download
0
Category
Tags:
Preview:
Citation preview
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.
Recommended