[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Registration and Party IDs
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. 101 First Street, Suite 552 Los Altos, CA 94022 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: Bartell, Bruce [mailto:bbartell@xtensible.net] 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. 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:Toby.Considine@gmail.com] 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]