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