[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Registration and Party IDs
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]