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