[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Registration and Party IDs
All of the items I have mentioned are
already covered by the emix substitutionGroup emix:emixInterface. Bruce
Bartell Xtensible Solutions From: Ed Cazalet
[mailto:ed@cazalet.com] Thanks. I responded to your questions
inline below – labeled Ed. From: Holmberg, David
[mailto:david.holmberg@nist.gov] Thanks Ed, I took a careful read of your Ei
Registration from TEMIX perspective pdf document sent around earlier (text
below) and see now that Party is more aligned with customer than a resource.
And in the TEMIX view, a Party might enter into contracts with no
resource—like for forward power purchases. Or a Party may have resources
that are physically a generator, or (not-so-physically) some aggregated DR load
shed. Some comments inline below. Thanks, 1. Party registers with 1 t0 *
Counter Parties or with 1 to * Party Registries. ·
Where is enrollment here, as opposed to registration? Ed: Registration as
defined here only identifies parties to each other so that if they choose they
can enter into Enabling Agreements with each other. Such Agreements can be to
enroll in a DR Program or a Wholesale Trading Agreement. 2. Party can also registers 1 to
* Accounts with each Counter Party or Party Registry ·
Per Phil’s comments, an account is a
customer+premise+meter. What you are calling an Account seems more like what we
are calling a resourceID, although in TEMIX it’s the registration in a
market. Ed: I think of Account as logical way
to segment the activities of a Party for various purposes. Think of the
various bank, credit card, and online accounts we all have. An account could
be a customer+premise+meter or a generatorOwner+generator+meter. However, for
generators we usually use resource or device ID that are associated with an
owner. A DR Resource could be associated with an Account, I suppose, but I
would expect to see a Resource ID that is associated with a Party and an
Account. 3. Discovery of Counter Parties
and Parity Registries is a search process that is out of scope. 4. Party and one or more
accounts also associates with one or more Energy Service Interfaces as owner. ·
PartyID plus ResourceID (in the context of a single
market) points to a single ESI/VEN. Ed: OK 5. Each ESI has location
attributes as described in emix. Locations are called Nodes. 6. An ESI may be a controller
for devices such as air conditioners, generators, or PEVs. 7. A meter may be associated
with and ESI. ·
Or multiple meters, per the last discussion. Ed: OK 8. A Party may transact at other
ESI nodes that may not have meters or have meters that the Party does not own. ·
I don’t understand this. Ed :A Party may transact at Trading
hubs, for example where there is no meter or at Generating Hubs where it does
not own any of the meters.. This is typical for wholesale trading. 9. Devices such as generators
are also called Generating Resources. Generating Devices on the Distribution Grid are
call Distributed Energy Resources. 10. Devices may consume or
product electric energy while producing revenues for generating devices and services
at a cost for consuming devices. 11. The ESI for a device may
control the device based on preferences of the owner. 12. A Party or an ESI acting for
a party may agree to forward transactions for energy. ·
Is a Party = customer at a SDP? So, not a resource, but I
have to at least say which premise and which meter, right? So, from the TEMIX
perspective the Party is the customer and an associated SDP, and the resource
might not be there. Ed: A Party is a customer such as
Target, or a Generator such as Calpine. Thus the customer may have many
associated SDPs (EMIX Interfaces) where it typically uses electricity or in the
case of Calpine where it operates generators at EMIX Interfaces. 13. A Party and Account and ESI
may enroll in Agreements offered by Counter Parties. A retail tariffs be one such
agreement. A Participation Agreement in an ISO or RTO is another. And a Party already
enrolled in a retail tariff with a utility counter Party may also enroll in a Demand Response
Program. 14. An Account for a Party may
take the role of buyer or seller for energy transactions under enabling agreement with counter
parties. 15. An Account for a Party
enrolled in an ISO or RTO may submit tenders to their markets. The tenders may be for either
energy and ancillary service products or for resource capability. The ISO or RTO
accept the tenders at market clearing prices or may dispatch the resource and pay market clearing prices for products
produced. Edward G. Cazalet, Ph.D. 650-949-5274 cell: 408-621-2772 From: Ed Cazalet
[mailto:ed@cazalet.com] A Party can be a customer, generation
owner, ISO, LSE, marketer, DR Aggregator, Storage owner, Distribution Operator
and so. A Party is not a Resource. A Party may own a generation
resource or enroll a Demand Response Resource in a Program operated by another
Party such as a DR Aggregator. Edward G. Cazalet, Ph.D. 650-949-5274 cell: 408-621-2772 From: Holmberg, David
[mailto:david.holmberg@nist.gov] I think Bruce is agreeing with me. Also,
here are some related follow-on observations, if I am on the right track: ·
A customer can have multiple ESIs (VENs) each as face to
a resource. In fact a resource can have multiple VENs each with a different
PartyID representing that same resource to different markets, if such behavior
is permitted by market rules. But from the program-operator/market-operator
perspective, they see a resource with a single VEN (and single PartyID). ·
What is the difference then between a ResourceID and a
PartyID? Lets say a customer has a DR resource that is very flexible and can
participate in multiple programs offered by some utility (a single
Registrar with multiple market-contexts). The resource is enrolled as a Party
and gets a PartyID, but then gets separate ResourceIDs for each program it
registers for. ·
Is this right then: I enroll a resource and get a
PartyID, then register that same Resource in a specific program
(market-context) and get a ResourceID? Seems that enrollment allows me to say,
“here is a Party (aka Resource) that can participate in any available
programs (aka market-contexts) that you the Registrar (some enrollment agency)
has available.” I provide contact info, customer ID, SDP/meter mRID,
billing address, credit history, etc. needed for enrollment as required. After
that I can register that Party (resource) for a specific program and get a
ResourceID. David From: The customer can have multiple resources.
The resource must be associated with a single Service Delivery Point at the customer
service location. How the billing is consolidated for multiple resources for a
customer is a back-office issue only. The resource must be associated a single
Service Delivery Point which is associated a Meter Asset which has a Meter
Asset mRID. So a customer can have multiple resources at multiple locations. We
need to preserve the resource->SDP->Meter relationship for baseline and
settlement. I’m not sure we need to include a meter id in the model at
all. I don’t see how ESI even enters into
the conversation for enrollment. We just need to know where to send the message
for a resource. Bruce
Bartell Xtensible Solutions From: Holmberg, David
[mailto:david.holmberg@nist.gov] So, let me revise my previous set of
statements. ·
I was wrong to say that a customer enrolls and gets a
PartyID. The customer enrolls and gets some Enrollee ID (which is tied to a
market, and may be the same as an Enroller’s CustomerID for that
customer, and if there is no Enrollee ID, then do we need an enrollment
service?). The customer-owned resource then registers that resource in a
market-context/program and gets a resourceID. ·
That Resource has a single ESI as a single VEN. ·
I agree with Toby that a VEN is a set of services for an ESI. An ESI is a services
interface. I (the VTN) carry a conversation with it. If a single resource has
multiple ESIs, then how can I carry the same conversation with 3 ESIs? Which
ESI is the voice of the resource? ·
I think the confusion is the question Ed
raised—where, “a ‘customer’ which can certainly have
more than one ESI (campus, etc) will then have multiple VEN’s and what
are the consequences of that if a customer is considered a single DR Resource
by the Utility?” o
To that I say that a utility can regard a customer as a
single resource if and only if it has a single ESI/VEN. Again, how do you carry
the same conversation with multiple VENs/ESIs? Maybe I’m missing
something. ·
I still need to rationalize my statements with
EdC’s TEMIX perspective. Thanks, From: Koch, Edward
[mailto:Edward.Koch@Honeywell.com] I'm not recommending that we
specifically add support for "customers". I'm only using them to
ground our abstract concepts in reality. The important aspect of customers is
that they have a financial relationship with utilities and they are typically
considered a single DR resource yet they may have multiple ESIs that they are
using with that resource. We just need to make sure that our notion of
resource, VTN, and ESI supports the relationships that may be implied by my use
case. From: Toby Considine
[mailto: I think that a VEN is a defined set of
surfaces for an ESI. A PartyID is what an ESI gets when it
Registers. It may then choose to enroll that PartyID as a VEN. It may also do
both together using the RegisterMeNow flag in enrollment. If an ESI registers more than once, it
may get more than one PartyID. A PartID is part of a VTN Announcement.
How a Party announces that it is presenting a VTN surface has never been
discussed. Customers are out of scope. A
customer-based DB may know that 25 of the PartyIDs that it owns are associated
with a customer ID in PGE, and another 15 PartyIDs that it owns are associated
with a customer ID in SCE. Presumably PG&E knows that those PartyIDs are
the same customer, but it is never necessary during any service other than
Registration/Enrollment, if then. Possible uses for a CustomerID: Please EnrollPartyID in wacka-wacka
program. Please EnrollPartyID in wacka-wacka
program as Customer ###. This would make CustomerID optional, and
used only during enrollment When else would there be a need for the
CustomerID in EI Services? tc "He who fights with monsters should
look to it that he himself does not become a monster, and if you stare long
into an abyss, the abyss also stares into you." - Fredrich
Nietzche
From: Koch, Edward
[mailto:Edward.Koch@Honeywell.com] David, I think the best way to discuss my use
cases is to substitute the word ESI for Client. That is really what a client
is. We have never really discussed the
relationship between the ESI and the VEN, specifically what is the consequences
of a VEN having more than one ESI or do we not allow that? If not then we have
to concede that a “customer” which can certainly have more than one
ESI (campus, etc) will then have multiple VEN’s and what are the
consequences of that if a customer is considered a single DR Resource by the
Utility. Thanks, -ed Koch From: Holmberg, David
[mailto:david.holmberg@nist.gov] Some thoughts to see if I get it, and I
think this is all consistent with discussion so far: ·
In Ed’s example use case, a customer enrolls, and
is given a participant ID which I take to be associated with registration of
that participant (it seems that Ed’s example conflates enrollment and
registration). Then a participant = one resource associated with one meter,
with any number of client URLs to send messages to. Presumably a customer can
enroll multiple participants/resources. ·
VENs are the service endpoints for a particular VTN/VEN
relationship for which there may be more than one VEN per participant/resource,
or perhaps multiple participants per VEN when we have aggregation. I would say
that from the customer side, there may be multiple VENs/clients per resource,
but only because the customer registers that resource for multiple programs or
market contexts. The VTN only ever sees a single VEN/client per resource.
(question, did we agree to NOT provide a means to indicate a VEN as an
aggregated resource with some set of indicated resources behind it? Is there a
need for that ever?) ·
So, what is the relationship between Ed’s
“client” and the VEN? The VEN is associated with a resource. A
customer registers a resource, with an associated VEN. In Ed’s example, a
VEN may include multiple clients, like a list of “send the message to
these URLs”. But how does that work with feedback, or two-way service
exchanges in general? I guess we could have multiple URLs for one-way
communications, but we don’t have much one-way only communications, so
maybe we just limit a VEN to one client address in EI? ·
Meters are associated with resources (the meter provides
M&V for whatever is behind it). A customer may have multiple resources. The
customer might be Target HQ, with each individual Target store as a resource,
each with a VEN. From the VTN perspective, each resource is associated both
with a customer and a meter. From the customer perspective, each resource is
associated with a meter and a set of VTN/VEN pairs (if there are multiple
market contexts for that resource). ·
“And just register me while you are at it”
flag on the enrollment. If PG&E is a registrar, then the customer enrolls
and says, “and please register THIS resource for THIS program while
you’re at it” ·
Customer = PartyID, which may have multiple Resources,
each associated with a metrology point (MeterID). I think PartyID is unique to
the registrar, but the same customer may enroll with different registrars and
given different PartyIDs. Thus, a customer has one unique PartyID only in the
case of a single registrar, either because the customer is only interested in a
single market context, or because there is a single uber-registrar covering
multiple market contexts. ·
Bill’s submetering question is very interesting.
Today, utilities only read their own meters, to my knowledge, but in EI we are
setting up EIDelivery to allow verification based on a customer owned sub-meter
(with some MRID agreed upon by utility and customer), and thus to allow for a
resource defined based off of a customer-owned meter. We are assuming that
there will be some way to make this approach acceptable to the utility (i.e.,
that part is out of scope), probably by the efforts of some coalition of
utilities and customers (OADR-A?). Do I see this right? HTH, David From: Koch, Edward
[mailto:Edward.Koch@Honeywell.com] In all this re-jiggering of the concept
of VEN and Resource I want to make sure that we are not losing sight of a very
important use case and I understand how it is supported in the new structure.
The following is an example of what is done today. I’m not claiming
that this is a universal scenario or use case that covers everything, but it is
typical. I will speak in very explicit terms using the terminology used in
today’s DR programs. I will leave it to others to make sure these
get translated into the appropriate EI terms and structures. A utility (i.e. PG&E< SCE, etc)
has DR programs that their customers can enroll in. When a Utility customer enrolls in a DR
program there is instantiated logical entity call a “participant”
and the participant entity receives an account id which sometimes is the same
as the customer’s meter account. How the account id is generated is
irrelevant and depends entirely on how the utility wants to do it. Each participant in a particular program
represents a single DR Resource that the Utility can dispatch or interact with. It may be possible for the Utility to
aggregate participants (and their DR Resources together) to form aggregated
groups but this is not something that requires an inter-domain interaction to
facilitate. In addition to the participant entity
there are generated what are called “client” entities. The
clients are the entities that receive the DR signals and each customer can have
one or more clients associated with their participant account. Often the client
entities are created by the customers themselves and represent where they would
like the DR signals to be delivered. For example the customer may want to
deploy one client per floor in the building. Meters are associated with participants
(NOT clients). In short there does not need to be a one to one
correspondence between meters and clients. DR Resources are associated with
participants not clients. The clients are only a means for the customer
to interact with the Utility to receive DR signals and do not map to any
financial relationship or commodity such as DR Resources. So in EI terminology if a customer is a
VEN that establishes some sort of relationship and financial obligation with a
VTN (i.e. Utility) concerning their DR Resource, then what is a client?
Are we not supporting the notion of a customer with multiple clients that each
can receive a DR signal or is each client a VEN that are all attached to the
same customer account and DR Resource? This is an important point because
depending upon how you establish the VEN/DR Resource relationship and the rules
around it will define what is possible. In my opinion a DR Resource is a
commodity that is associated with a customer that has an account as part of a
market context. On the other hand a VEN has services defined on it with well
defined message exchanges. Thus a VEN in and of itself is NOT a DR Resource nor
is it a customer, it is simple a party whose role is to facilitate interactions
between customer’s and service providers about resources. Hopefully we
can agree about that. The only question then is what is the relationship
between VEN’s, customers and resources. From what I can tell we have to
support multiple DR Resources and customers behind a single VEN, i.e.
aggregation, but we also may have to associate multiple VEN’s with a
single customer and resource as in the scenario described above. Whatever we do
the model needs to be flexible. On a separate, but related note it
should not be a requirement that when a customer (or whatever we are calling
that entity in the new world) swaps out their HW/SW that they have to
re-register with the VTN. It may be that re-registering with the VTN is
in fact a preferred method of getting the necessary configuration information
and credentials into the HW/SW, but if the customer can clone the necessary
data from the old HW/SW into the new HW/SW then re-registering should not be
necessary or required. Thanks, -ed Koch From: Toby Considine
[mailto:tobyconsidine@gmail.com] On Behalf Of
Toby Considine Primarily
for Gerry and Bruce: A
primary purpose of Registration is to receive a Party ID for interacting with
the market. During enrollment, one can associate that Party ID with one or more
metrology points, which may happen to be specific revenue meters. 1) In
emerging markets closely allied with existing markets, should the Party ID by
an MRID? 2) If
a truck drives into my meter, and I get a physically new meter (with a new
faceplate, etc.) does this change my MRID in today’s infrastructure? 3) If
I register multiple Resources, is there a pre-existing definition of MRID as it
relates to the submetering meter ids? In
a closely related question, Say I switch out the software and hardware that
operates my ESI. I then re-register and rejoin the market contexts. In
some market contexts, there may be non-trivial “establishment”
costs. These might include posting a bond, establishing a line of credit, etc.
I may get different value for my response based upon a reputation that my
[Party ID] has established for fast, accurate performance. It
would be useful to join my new registration ID to the pre-existing identity in
some way. This is the ill-defined Account. Any
thoughts? tc “The
single biggest problem in communication is the illusion that it has taken
place.”
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]