[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Registration and Party IDs
|
There is no contradiction at all. All you
need are the reads for each resource at the delivery point associated with the
aggregator. Dave’s point on the M&V process explains the rest. Bruce
Bartell Xtensible Solutions From: Holmberg, David
[mailto:david.holmberg@nist.gov] Yes, so a VEN/ESI
represents this single aggregated resource. How do we handle M&V then?
Maybe this is the question that EdK was asking—how does the utility or
market verify that an aggregator has delivered the Resource when there are
multiple meters in the background that it cannot see, rather than one meter
(that it owns) associated with the VEN? This use case seems to go against the
statements just made by Bruce: ·
“A customer can have multiple DR Resources. The only restriction is
that a resource must be associated with a Service Delivery Point. A Service
Location can have multiple Service Delivery Locations. And a Customer can have
multiple Service Locations and/or Service Delivery Points.” David From: Toby Considine
[mailto:tobyconsidine@gmail.com] On Behalf Of
Toby Considine I mention that because we shouldn't
lock components to a specific ESI for example. All devices in a building may
work through a single ESI to react to a price event. However, all the
variable speed drives in a city block might work through another ESI, bypassing
the premise ESI, when providing regulation services. Pulling out the
paragraph above to make sure no one misses it…. "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: pddcoo@gmail.com
[mailto:pddcoo@gmail.com] On Behalf Of Phil
Davis As I read through this thread, there are some areas of mild confusion
(for me). In Ed's comments, there are customers, VTN's (eg utility) and so forth
that seem to act like business counter parties (i.e., human). The VEN,
a.k.a "Client" seems to use "client" in the technical sense
(HW/SW based). Thus reading sentences combining "customer" and
"client" can be challenging to mere mortal understanding. There
is another area or two that might bear clarification. Dave says "the
meter provides M&V for whatever is behind it" which
technically is not the usual case. Meters measure, and M&V reports on
the veracity of the meter. That normally occurs at a central meter
consolidation point, e.g., the utility, with a separate system like Itron's
MV90. Again a minor point but important if you're speaking with metering
folks. The key question seems to be around the relationships between sentient
actors (human) and the devices they employ to carry out those actions.
Just to be coy, start with the idea that people do not use electricity.
They use devices to accomplish some task, and those devices use
electricity. Similarly, buildings (which are metered in the utility
sense), do not use electricity. They contain devices (generally not
metered) that do. Therefore, potential physical aggregations can be: 1. All devices within a building 2. All devices under the influence of a common subsystem (e.g.,
lighting) 3. Individual unrelated devices that have common characteristics
allowing virtual aggregation independent of their physical connections and
surroundings (batteries, drives) 4. Combinations of the above linked to specific electrical
circuits defined by the grid owner While potential contractual (business) aggregations can be: 1. Any combination of the above that an aggregator can commit to a
contract and then sell to a willing buyer bilaterally or via market rules. 2. An aggregator can be any business entity such as an
individual, a facility owner, a tenant, a utility, a third party and so on. 3. The relationship potentials between any of these pieces is
many-to-many. There must be a way to address all of these uniquely; but that
uniqueness need occur only within an area where there is possible overlap. The
spectrum can range from something like a MAC address (unique device) to a phone
number (unique only when its elements are combined such as local
number+exhange+area code+country code. The latter requires a relatively
static and orderly world, whereas the former lends itself to thriving in chaos. To some extent, the responding "stock" of devices already has
some fairly sophisticated addressability. For example, if a building has
a BMS, then there is a good chance that individual components have a unique
register address that allows the BAC or LON message to find its way. The
MAC concept for devices is less common, but it's coming. So perhaps an ESI should be equivalent to a VEN. A PartyID should
be the enabling emblem of the contract to be enforced and so could associate
with ESI representing the device bundle called on to act. What the ESI
does behind its interface is an imponderable best left to used car sales types. Through customer, there are a number of ID labels floating around, and
we shouldn't intermingle terms. For example, a meterID is a utility designator
for a physical device. If that meter is replaced, the new meter has
another meterID. A premiseID is a facility with a physical address.
If a building is destroyed and another built in the same spot, the
premise ID stays the same. An account number (ID) is a contracting party
or customer. If a customer moves, it takes that account number with it to
the new location. A billing relationship is defined when the necessary
and sufficient combination of accountID, premiseID and meterID come together.
This is why utilities find it challenging to bill for something that is
not related to a premise. I mention that because we shouldn't lock components to a specific ESI
for example. All devices in a building may work through a single ESI to react
to a proce event. However, all the variable speed drives in a city block
might work through another ESI, bypassing the premise ESI, when providing
regulation services. I hope some of this was comprehensible. Phil Davis | Senior Manager - Solutions | On Tue, Jul 26, 2011 at 11:51 AM, Holmberg, David <david.holmberg@nist.gov>
wrote: 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]