Distributed Generation Aggregator
1 Descriptions of Function
All prior work (intellectual property of the company or individual) or proprietary (non-publicly available) work should be so noted.
1.1 Function Name1
Distributed Generation Aggregator
1.2 Function ID2
IECSA identification number of the function
1.3 Brief Description3
Describe briefly the scope, objectives, and rationale of the Function.
The purpose of the distributed generation aggregator activity is to enable a mechanism whereby a system operator can call on
customers during peak periods of energy usage and who have backup generators to disconnect from the power grid and power
themselves with their generators.
1.4 Narrative4
A complete narrative of the Function from a Domain Expert’s point of view, describing what occurs when, why, how, and under what conditions.
This will be a separate document, but will act as the basis for identifying the Steps in Section 2.
In areas with high energy costs such as New York City, load curtailment programs have been initiated where facilities can make use of
on-site generators that provide back-up power and use them to supply peaking, reserve or load management capability. In many
instances, the size of the generators are in the 1 MW or so range and to make economic sense, it is necessary to aggregate multiple
units together into one virtual power plant that can be dispatched as would a normal power plant by system aggregators. The system
aggregator is responsible for the collection and aggregation of DG units. They generally have a contract to split revenues with the
owners of the DG units. The system aggregator is the point of interface to the system operator. The system aggregator also maintains
a control room and responds to calls and inquiries from the system operator before, during and after generation. The system
106744967
1
Printed 2/15/2016
aggregator generally owns and maintains all communication channels to the DG units as well as all of the monitoring equipment used
for performance verification. The system aggregator is responsible for calculating settlement and verification with the system operator
and distributing payments to the DG unit owners. The DG owners maintain the DG units and usually are responsible for starting and
stopping the units.
A typical scenario would be as follows. It is August in NYC and the temperature has hit the high 90s for the third straight day. As the
system peak continues to rise, the NYISO forecasts that there could be an energy shortage the following day. In response, the NYISO
asks approved system aggregators if they could shed load. In particular, the NYISO asks system aggregator #1 if it could supply 5
MW. The system aggregator then contacts its customers that are under contract if they could run their generators the following day.
The system aggregator then totals the amount of expected load that is expected to be relieved from the grid the following day and
submits that to the ISO. The system aggregator will try to obtain enough willing customers so that they can reach the 5 MW goal for
the day. When the next day arrives, the system aggregator then follows up with each customer to remind them to disconnect from the
power grid and to start their generators. The system aggregator and/or system operator monitors over the Internet the output from
each generator and totals them to ensure compliance with the 5 MW load. It is important to get near what is asked for maximum
revenue can be obtained and to avoid penalties. If a generator fails to start, the system aggregator attempts to get another customer to
start their generator. At the end of the day, the generators are stopped and data is collected that is used to verify compliance and to
calculate bills that go to the ISO. The system aggregator submits the bills to the ISO and once payment is received, the corresponding
revenue is sent to the DG unit owners.
1.5 Actor (Stakeholder) Roles
Describe all the people (their job), systems, databases, organizations, and devices involved in or affected by the Function (e.g. operators, system
administrators, technicians, end users, service personnel, executives, SCADA system, real-time database, RTO, RTU, IED, power system).
Typically, these actors are logically grouped by organization or functional boundaries or just for collaboration purpose of this use case. We need
to identify these groupings and their relevant roles and understand the constituency. The same actor could play different roles in different
Functions, but only one role in one Function. If the same actor (e.g. the same person) does play multiple roles in one Function, list these different
actor-roles as separate rows.
106744967
2
Printed 2/15/2016
Grouping (Community) 5, 6
Group Description 7
DG aggregation top level
Top level group with all important actors
Actor Name 8
Actor Type (person, device, system
etc.)9
Actor Description 10
System
Aggregator
Person
Entity responsible for the collection, aggregation and dispatch of DG units
in response to direction from a system operator
System
Operator
Organization
Responsible for the operation of the power grid in a particular region.
Gives commands to the system aggregators
DG Owners
Person
Owns the DG units used by the system aggregators to supply loads
Monitoring
Equipment
Device
Collects data to be used for verification and billing purposes
Central
Database
System
Takes real-time and collected data from the monitoring equipment and
stores in database for later settlement
Communication
Device
Allows for real-time communication between the generators and system
aggregators and/or system operators
Control
Equipment
Device
In some instances, the control equipment can be used to remotely control
the DG units
Replicate this table for each logic group.
1.6 Information exchanged
Describe any information exchanged in this template.
106744967
3
Printed 2/15/2016
Information Object Name 11
Information Object Description 12
Generator Request
Request from system operator to system aggregator for a specific amount of load that can be relieved
from the grid
Energy Data
Hourly and current Watt-hours, voltage, current, real and reactive power, etc.
Generator status
Generator status and outputs
Settlement Data
Report submitted to system operator containing settlement and verification information
1.7 Activities/Services
Describe or list the activities and services involved in this Function (in the context of this Function). An activity or service can be provided by a
computer system, a set of applications, or manual procedures. These activities/services should be described at an appropriate level, with the
understanding that sub-activities and services should be described if they are important for operational issues, automation needs, and
implementation reasons. Other sub-activities/services could be left for later analysis.
Activity/Service Name 13
Activities/Services Provided 14
Accounting and settlement
System aggregator produces all settlement reports for generation verification that get submitted
to the system operator
Real-time monitoring and
aggregation page
System aggregator collects real time readings from individual generators and aggregates and
displays over web page
1.8 Contracts/Regulations
Identify any overall (human-initiated) contracts, regulations, policies, financial considerations, engineering constraints, pollution constraints, and
other environmental quality issues that affect the design and requirements of the Function.
Contract/Regulation 15
Impact of Contract/Regulation on Function 16
Contract between system
Contract between system aggregator and DG unit owner committing DG unit owner to provide
106744967
4
Printed 2/15/2016
Contract/Regulation 15
Impact of Contract/Regulation on Function 16
aggregator and DG unit owner
generation when needed by the system operator for a negotiated fee.
Policy17
Generation
Constraint 24
From Actor 18
DG Owners
Type 25
Environmental Emissions
106744967
May 19
Shall
Not 20
Description (verb) 22
Shall
To Actor 23
21
X
Provide use of DG units when required by the system
operator
Description 26
Applies to 27
In general, due to emissions requirements, the DG units
can not be run for significant amount of hours in any one
year
Overall program
System
aggregator
5
Printed 2/15/2016
2 Step by Step Analysis of Function
Describe steps that implement the function. If there is more than one set of steps that are relevant, make a copy of the following section grouping
(Preconditions and Assumptions, Steps normal sequence, and Steps alternate or exceptional sequence, Post conditions)
2.1 Steps to implement function
Name of this sequence.
2.1.1 Preconditions and Assumptions
Describe conditions that must exist prior to the initiation of the Function, such as prior state of the actors and activities
Identify any assumptions, such as what systems already exist, what contractual relations exist, and what configurations of systems are probably in
place
Identify any initial states of information exchanged in the steps in the next section. For example, if a purchase order is exchanged in an activity, its
precondition to the activity might be ‘filled in but unapproved’.
Actor/System/Information/Contract 28
Preconditions or Assumptions 29
System Operator
Monitoring the power grid and determining that energy shortage may occur
System aggregator
Standing by, waiting for signal from system operator
106744967
6
Printed 2/15/2016
2.1.2 Steps – Normal Sequence
Describe the normal sequence of events, focusing on steps that identify new types of information or new information exchanges or new interface
issues to address. Should the sequence require detailed steps that are also used by other functions, consider creating a new “sub” function, then
referring to that “subroutine” in this function. Remember that the focus should be less on the algorithms of the applications and more on the
interactions and information flows between “entities”, e.g. people, systems, applications, data bases, etc. There should be a direct link between
the narrative and these steps.
The numbering of the sequence steps conveys the order and concurrency and iteration of the steps occur. Using a Dewey Decimal scheme, each
level of nested procedure call is separated by a dot ‘.’. Within a level, the sequence number comprises an optional letter and an integer number.
The letter specifies a concurrent sequence within the next higher level; all letter sequences are concurrent with other letter sequences. The
number specifies the sequencing of messages in a given letter sequence. The absence of a letter is treated as a default 'main sequence' in parallel
with the lettered sequences.
Sequence 1:
1.1 - Do step 1
1.2A.1 - In parallel to
1.2A.2 - In parallel to
1.2B.1 - In parallel to
1.2B.2 - In parallel to
1.3 - Do step 3
1.3.1 - nested step 3.1
1.3.2 - nested step 3.2
activity
activity
activity
activity
2
2
2
2
B
B
A
A
do
do
do
do
step
step
step
step
1
2
1
2
Sequence 2:
2.1 - Do step 1
2.2 – Do step 2
106744967
7
Printed 2/15/2016
# 30
Event 31
Primary Actor 32
#
Triggering event?
Identify the name
of the event.1
What other actors
are primarily
responsible for the
Process/Activity?
Actors are defined
in section1.5.
1.1
System
Operator
Initiates
Curtailment
1
System
Operator
Name of
Process/Activity 33
Label that would
appear in a
process diagram.
Use action verbs
when naming
activity.
System
Aggregator
Notification
IECSA Environments
Description of
Process/Activity 34
Information
Producer 35
Information
Receiver 36
Name of Info
Exchanged 37
Additional Notes 38
Describe the actions that take
place in active and present
tense. The step should be a
descriptive noun/verb phrase
that portrays an outline
summary of the step. “If
…Then…Else” scenarios can
be captured as multiple
Actions or as separate steps.
What other actors
are primarily
responsible for
Producing the
information?
Actors are defined
in section1.5.
What other actors
are primarily
responsible for
Receiving the
information?
Actors are defined
in section1.5.
Name of the
information object.
Information objects are
defined in section 1.6
Elaborate
architectural issues
using attached
spreadsheet. Use this
column to elaborate
details that aren’t
captured in the
spreadsheet.
During a heat wave,
the system operator
forecasts that a
possible energy
shortage may exist
the following day
and therefore
contacts approved
system aggregators
and asks them if
they can provide a
set number of MWs
the following day
System
Operator
(Note – May leave
blank if same as
Primary Actor)
System
Aggregator
Reference the applicable
IECSA Environment
containing this data
exchange. Only one
environment per step.
Generation
Requests
Note – A triggering event is not necessary if the completion of the prior step – leads to the transition of the following step.
106744967
8
Printed 2/15/2016
# 30
Event 31
Primary Actor 32
Name of
Process/Activity 33
Description of
Process/Activity 34
Information
Producer 35
Information
Receiver 36
Name of Info
Exchanged 37
1.2
System
System
Aggregator
Aggregator
Polls DG
Unit Owners
DG Unit
Owner PreNotification
System aggregator
contacts individual
customers
requesting that they
separate from the
grid and run off
their generators
System
Aggregator
DG Owners
Generation
Requests
1.3
Generation
Start Time
System
Aggregator
DG Unit
Owner On
Notification
System aggregator
contacts customers
at the start time to
make sure customer
complies with
request
System
Aggregator
DG Owners
Generator
Status
1.4
Monitoring
System
Aggregator
DG Unit
Monitoring
System aggregator
monitors in realtime the generator
output to verify goal
is being met
Monitoring
Equipment
Central
Database
Energy Data
1.5
Generation
End Time
System
Aggregator
DG Unit
Owner Off
Notification
System aggregator
contacts customers
at the end time to
make sure customer
shuts down
generators
System
Aggregator
DG Owners
Generator
Status
106744967
IECSA Environments
Additional Notes 38
Key
communication
requirements in
this step
9
Printed 2/15/2016
# 30
1.6
Event 31
Settlement
Primary Actor 32
System
Aggregator
Name of
Process/Activity 33
Settlement
Description of
Process/Activity 34
System aggregator
generates settlement
reports from the
data and submits to
the system operator
Information
Producer 35
Central
Database
Information
Receiver 36
System
Operator
Name of Info
Exchanged 37
IECSA Environments
Additional Notes 38
Settlement
Data
2.1.3 Steps – Alternative / Exception Sequences
Describe any alternative or exception sequences that may be required that deviate from the normal course of activities. Note instructions are
found in previous table.
#
Event
Primary Actor
Name of
Process/Activity
Description of
Process/Activity
Information
Producer
Information
Receiver
Name of Info
Exchanged
Additional Notes
2.1.4 Post-conditions and Significant Results
Describe conditions that must exist at the conclusion of the Function. Identify significant items similar to that in the preconditions section.
Describe any significant results from the Function
Actor/Activity 39
Post-conditions Description and Results 40
DG Units
Ready to go again in case needed
106744967
10
Printed 2/15/2016
IECSA
Environments
2.2 Architectural Issues in Interactions
Elaborate on all architectural issues in each of the steps outlined in each of the sequences above. Reference the Step by number. Double click on
the embedded excel file – record the changes and save the excel file (this updates the embedded attachment).
106744967
11
Printed 2/15/2016
2.3
Diagram
For clarification, draw (by hand, by Power Point, by UML diagram) the interactions, identifying the Steps where possible.
106744967
12
Printed 2/15/2016
3 Auxiliary Issues
3.1 References and contacts
Documents and individuals or organizations used as background to the function described; other functions referenced by this function, or acting
as “sub” functions; or other documentation that clarifies the requirements or activities described. All prior work (intellectual property of the
company or individual) or proprietary (non-publicly available) work must be so noted.
ID
Title or contact 41
Reference or contact information 42
[1]
[2]
3.2 Action Item List
As the function is developed, identify issues that still need clarification, resolution, or other notice taken of them. This can act as an Action Item
list.
ID
Description 43
Status 44
[1]
[2]
3.3 Revision History
For reference and tracking purposes, indicate who worked on describing this function, and what aspect they undertook.
No 45
Date 46
Author 47
Description 48
0.
106744967
13
Printed 2/15/2016
No 45
106744967
Date 46
Author 47
Description 48
14
Printed 2/15/2016
Endnotes
1
Function Name corresponds to the name attribute of a Use Case.
2
Function ID corresponds to the tagged value “id” attached to the Use Case.
3
Function description corresponds to the documentation attribute of a Use Case.
4
TBD - Documentation attribute of the Collaboration Diagram or perhaps the documentation element of the use
case.
5
Community [RMODP: Community] corresponds to a Classifier.
6
An Aggregation Association will be created between the Classifier corresponding to the Community and the Actor
corresponding to the Role – to represent the community membership.
7
Community Description corresponds to the documentation attribute of a Classifier.
8
The actor name corresponds to an Actor.
9
The Actor Type corresponds to the <<stereotype>> that is assigned to the Actor. Let’s not go crazy with
stereotype creation.
10
The Actor Description corresponds to the documentation attribute of an Actor.
11
The Information object name corresponds to the name attribute of a Classifier.
12
The Information object description corresponds to the documentation attribute of a Classifier.
13
The Service Name corresponds to a Use Case which is associated with the main domain template use case using
the <<includes>> relationship.
14
The Service Description corresponds to the documentation attribute of a Use Case.
15
Contract [RMODP: Contract] corresponds to a Classifier that aggregates owned Policy Classifiers.
16
Contract Description corresponds to the documentation attribute of a Contract Classifier.
17
Policy [RMODP: Policy] corresponds to a Classifier. A Policy Classifier is an associated classifier using the
Permission association.
18
The “From Actor” corresponds to an existing Actor.
19
Permission [RMODP: Permission] corresponds to a policy classifier operation with the <<permission>>
stereotype assigned.
20
Prohibition [RMODP: Prohibition] corresponds to a policy classifier operation with the <<prohibition>>
stereotype assigned.
21
Obligation [RMODP: Obligation] corresponds to a policy classifier operation with the <<obligation>> stereotype
assigned.
106744967
15
22
Description of the Policy Permission, Prohibition, or Obligation corresponds to the documentation attribute of the
Policy Classifier Operation.
23
The “To Actor” corresponds to an existing Actor.
24
Constraint corresponds to the Constraint Attribute of the Actor/Classifier/Interface that its applied to.
25
TBD – Probably Ignored ?
26
Description of the Constraint corresponds to the documentation attribute of Constraint.
27
“Applies to” corresponds to the named Actor/Classifier/Interface the constraint is bound to.
28
TBD
29
TBD
30
TBD - Numbering may not directly correspond to numbering in a collaboration diagram.
31
Triggering Event corresponds to a ClassifierRole that serves as an Activator.
32
Information receiver corresponds to a ClassifierRole having a base Classifier assigned to an existing Actor,
Classifier or Interface.
33
Name of Activity corresponds to name attribute of an Action.
34
Description of Activity corresponds to documentation attribute of an Action.
35
Information receiver corresponds to a ClassifierRole having a base Classifier assigned to an existing Actor,
Classifier or Interface.
36
Information producer corresponds to a ClassifierRole having a base Classifier assigned to an existing Actor,
Classifier or Interface.
37
Name of Info Exchanged corresponds to the name attribute of a Message.
38
TBD – Constraint attribute of some or multiple relationships?
39
TBD
40
TBD
41
Reference corresponds to the name attribute of an Artifact having the <<document>> stereotype assigned.
42
Reference corresponds to the documentation attribute of an Artifact having the <<document>> stereotype
assigned.
43
No correspondence
44
No correspondence
106744967
16
45
Revision Number corresponds to the documentation attribute of an Artifact having the <<document>> stereotype
assigned. All information added to the model will utilize the “reference” tagged value to refer to the Artifact. The
Artifact representing this domain template will utilize the “reference” tagged values to refer to the source material.
46
Date corresponds to the documentation attribute of an Artifact having the <<document>> stereotype assigned. All
information added to the model will utilize the “reference” tagged value to refer to the Artifact. The Artifact
representing this domain template will utilize the “reference” tagged values to refer to the source material.
47
Author corresponds to the documentation attribute of an Artifact having the <<document>> stereotype assigned.
All information added to the model will utilize the “reference” tagged value to refer to the Artifact. The Artifact
representing this domain template will utilize the “reference” tagged values to refer to the source material.
48
Description corresponds to the documentation attribute of an Artifact having the <<document>> stereotype
assigned. All information added to the model will utilize the “reference” tagged value to refer to the Artifact. The
Artifact representing this domain template will utilize the “reference” tagged values to refer to the source material.
106744967
17