Please see my update to David’s definitions below.
Energy Interop model term definitions, DGH 7/28/2011 draft 2 modified by Ed Cazalet 7/29 |
| |
Party | A Party is a customer or business entity. A Party establishes an identity for itself including one or more PartyIDs and associated Account IDs with a registration authority. The registration authority may be independent or operated by other Parties. A Party may enroll in Markets (ISOs, tariffs, bilateral trading agreements, programs, etc.). A Party may receive IDs relevant to a specific Market via enrollment/registration. A Party also may be a DR Operator under contract to operate a DR Program for a utility or ISO. |
Resource | A Party may identify and register Resources (each with associated premise address and measurement point). A Party may also own zero Resources, such as a typical purchasing customer or a Party or trading in the wholesale forward markets (however a purchasing customer would have a premise address and measurement point.) A customer may also enroll as a Participant in DR Programs each with a DR Operators. For each DR Program, a customer may register a DR Resource. A DR Operator may aggregate DR Resources of its Participants and present a DR Resource to an ISO. The EMIX Resource.xsd model describes a range of potential operational responses for any resource. The model allows parties to describe a wide range of operations, both generation and curtailment. [EMIX Section 13]. Resources may represent a generator or a load response or aggregations. In interactions involving Resources it may be useful to describe either (1) the proposed or actual operation of a Resource, or (2) the range of capability of a Resource. EMIX Resource Descriptions are an extension of the EMIX Product Description. A Product is a description of place, commodity and schedule (intervals) in the context of a tender or transaction. A Resource must have an associated measurement point. For a physical generator or facility providing DR, this may be the utility meter. It could also be an aggregation of meter data for an aggregated Resource. Or it could be a sub-meter value or estimated measurement value (no real sensor) for some real or virtual generator within a facility.
|
Meter | A physical meter with a meter ID or measurement points, since meters (traditional physical sensor on an electric line) are not always required to provide a sufficiently accurate measurement. |
| |
| |
ESI | An ESI is the service interface point . The ESI is the logical interface point which might have a HW box you can point to. An ESI may be associated with one or more(?) Meters or Measurement Points. |
Side | Side taken by a Party in a transaction ( buy side or sell side). |
Participant | A Party enrolled as in a Participant in an ISO Markets, an Independent Exchange or a DR Program. |
OADR client | In EI there is no client in the OpenADR sense. A DR Resource has a URL; as do the DR Operators for each Program it is enrolled with. The two Parties communicate using services such as EiRegister/EiEnroll, EiAvail and EiOpt, EiFeedback and EiStatus. EiEvent notifications are to be optionally delivered to multiple URLs and optionally to pay attention to responses from each, but have a single VEN for a particular Resource that handles the services other than EiEvent responses. Alternatively, a Party owning a DR Resource could act as an Operator of DR Resources under his management and present an Aggregated DR Resource to his respective DR Operator. |
VTN | A VTN is a Party acting in the role of a Resource Manager or Operator (including an ISO) for one or more Resources, Generation or DR. |
VEN | A VEN is a Resource, Generation or DR owned by a Party. The Party responsible for a VEN may in tern be a VTN to other Resources or VTNs. |
Edward G. Cazalet, Ph.D.
101 First Street, Suite 552
Los Altos, CA 94022
650-949-5274
cell: 408-621-2772
ed@cazalet.com
www.cazalet.com
From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Friday, July 29, 2011 7:51 AM
To: Gerald Gray; Toby.Considine@gmail.com; 'Holmberg, David'; 'Bartell, Bruce'; 'Ed Cazalet'; 'Koch, Edward'; energyinterop@lists.oasis-open.org; 'William Cox'
Subject: RE: [energyinterop] Registration and Party IDs
I think it has to be.
If a Party can register resources in two different market contexts, then it can have more than one account….
Let’s walk through the range of this week’s examples that EdK and Phil provided
Chain, Ikea, multiple branches, in multiple Utility territories, potentially working with a different aggregator for each state. Say it enrolls with EnerNOC for Northern CA, directly with Sempra for San Diego, with SCE for Los Angeles. If the Party is IKEA, then that is three accounts…
Single store, Edkea, multicast from ESP (which may be PG&E) to the components of the registered resource.
Commercial Building, registers each floor as a separate resource in the same account to enable the ESP to give him an human-friendly UI for response
Commercial Building, registers AC as a DR asset with one ESP, registers all drives and motors in building to Utility as a Regulation service. Resources registered with two different companies, likely to be two different Accounts….
This is why I think we are not clear yet.
We have an ESI (which is a black box) with is associated with one or more Measurement Points which may be Meters or Virtual Meters, which may be Provider-owned or not, in accord with market rules.
An ESI can provide a number of services on behalf of a Party. Is the ESI identifier a PartyID? If a [building] has two ESIs, does it have two PartyIDs? I am not clear yet.
The thing associated with [owning?] an ESI can [enroll or register] with a number of other Partys exposing services. To do so, it presumeable sets up a means of payment, of billing, and may meet certain requirements [bond, line of credit, …] that qualify it to participate in that business relationship. I think we said on Wednesday that Utilities call this Enrolling, and ISOs Registering. It could be said that the Account is the name of this pre-qualification to do business. [Maybe we should call it Qualification]. This suggests that Account is many to Many. In the examples above:
Ikea might associate each new store built in SCE territory with an existing Account with SCE. This would require an ESI ID of some kind which can be either assigned to or associated with an Account. If the ESI ID == PartyID, then the Account might be the thing that can persist across Chain Stores…
If this is correct, then we have:
An ESI comes to market and is assigned a PartyID. During Enrollment in each Market, it is either assigned an Account, or becomes associated with an existing account.
During Registration, a Party that wishes to act as a VEN at defines a Resource (one or more WS Addressing points, and one or more Measurement Points, and a capability) with an Account in the market it is registering in. A Party may do this several times.
During Registration, a Party that wishes to act as a VTN at does what…
During Registration, a Party that wishes to transact does what…
Under this Model,
- an ESI can have any number of Accounts.
- An Account can be associated with any number of ESIs, each identified by a PartyID.
- A Resource works within a single Account as administered by a single ESI in its interactions with a single Market
The separation of the Admin and Operational interfaces of the VEN discussed yesterday I will not go into until we agree on the above…
[Note: Ed Cazalet’s reply crossed in the mail, and I believe it is compatible with the model below “If this is correct”]
tc
"It is the theory that decides what can be observed." - Albert Einstein
From: Gerald Gray [mailto:gerald.gray@guiding-principle.com]
Sent: Friday, July 29, 2011 10:01 AM
To: Toby.Considine@gmail.com; 'Holmberg, David'; Considine, Toby (Campus Services IT); 'Bartell, Bruce'; 'Ed Cazalet'; 'Koch, Edward'; energyinterop@lists.oasis-open.org; 'William Cox'
Subject: RE: [energyinterop] Registration and Party IDs
Is it possible for a Party to have more than 1 account?
From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
Sent: Friday, July 29, 2011 9:25 AM
To: 'Holmberg, David'; Considine, Toby (Campus Services IT); 'Bartell, Bruce'; 'Ed Cazalet'; 'Koch, Edward'; energyinterop@lists.oasis-open.org; 'William Cox'
Subject: RE: [energyinterop] Registration and Party IDs
If a party is a business entity with an associated account, what is an account?
Or is party what happens during [was registration, now identification? credentialing? Exposition?]
An account is created (or associated) during [enrollment or registration]
Resource associated with account during [registration or enrollment]
"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: Holmberg, David [mailto:david.holmberg@nist.gov]
Sent: Thursday, July 28, 2011 3:55 PM
To: Holmberg, David; Considine, Toby (Campus Services IT); Toby.Considine@gmail.com; 'Bartell, Bruce'; 'Ed Cazalet'; 'Koch, Edward'; energyinterop@lists.oasis-open.org; William Cox
Subject: RE: [energyinterop] Registration and Party IDs
Updated definitions based on the discussions on the EI call yesterday. Below and attached (includes notes).
Energy Interop model term definitions, DGH 7/28/2011 draft 2 |
| |
Party | A customer, some business entity, with an associated account. A Party establishes an identity for itself and registers in some market in order to interact in that market (tenders and transactions). It may identify and register Resources (each with associated premise address and measurement point). A Party may also own zero Resources, such as when purchasing forward power, or trading in the wholesale markets. A Party receives a PartyID relevant to a specific Market via enrollment/registration, and thus may have multiple PartyIDs. |
Resource | The EMIX Resource.xsd model describes a range of potential operational responses. The model allows parties to describe a wide range of operations, both generation and curtailment. [EMIX Section 13]. Resources may represent a generator or a load response or aggregations. In interactions involving Resources it may be useful to describe either (1) the proposed or actual operation of a Resource, or (2) the range of capability of a Resource. EMIX Resource Descriptions are an extension of the EMIX Product Description. A Product is a description of place, commodity and schedule (intervals) in the context of a tender or transaction. A Resource (may?) have an associated measurement point. For a physical generator or facility providing DR, this may be the utility meter. It could also be an aggregation of meter data for an aggregated Resource. Or it could be a sub-meter value or estimated measurement value (no real sensor) for some real or virtual generator within a facility. From the perspective of the VTN, a Resource has a single associated VEN. The Resource itself may be associated with multiple VENs if participating in service interactions with multiple VTNs. |
Meter | A physical meter with a meter ID. We agreed that we would favor speaking in terms of measurement points, since meters (tradional pysical sensor on an electric line) are not always required to provide a sufficiently accurate measurement. |
VTN | A role in a service interaction, the virtual top node. A Party enters a transaction, assuming a VTN or VEN role. |
VEN | A role in a service interaction, the virtual end node. A Party enters a transaction, assuming a VTN or VEN role. |
ESI | An ESI is the service interface point, acting as VEN or VTN. There is a 1 to 1 relationship with VTN/VEN. A Resource has a single VEN/VTN/ESI for each Counter Party (MarketContext). The ESI is the logical interface point which might have a HW box you can point to, while VTN/VEN denotes the role in the service interaction. |
buyer/seller | Roles in transaction (Each transaction/tender has a side). Not clear on relationship to VTN/VEN--those apply mostly to DR it seems, whereas buyer/seller to market transactions. |
Participant | Same as Party. A Participant may be uniquely assocated with a Resource if and only if it has only one Resource, as per some out of scope DR program requirement. |
OADR client | There is no client in the OpenADR sense. A Resource has an URL for its VEN; that is, there is a single VEN speaking for the Resource to handle: EiRegister/EiEnroll, EiAvail and EiOpt, EiFeedback and EiStatus. We may allow for EiEvent notifications to be optionally delivered to multiple URLs and optionally to pay attention to responses from each, but have a single VEN for a particular Resource that handles the services other than EiEvent responses. |
From: Holmberg, David
Sent: Wednesday, July 27, 2011 10:55 AM
To: 'Considine, Toby (Campus Services IT)'; Toby.Considine@gmail.com; 'Bartell, Bruce'; 'Ed Cazalet'; 'Koch, Edward'; energyinterop@lists.oasis-open.org; William Cox
Subject: RE: [energyinterop] Registration and Party IDs
A spreadsheet with some definitions for discussion.
David
From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Wednesday, July 27, 2011 10:05 AM
To: Holmberg, David; Toby.Considine@gmail.com; 'Bartell, Bruce'; 'Ed Cazalet'; 'Koch, Edward'; energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Registration and Party IDs
Some inconsistency here…
If a Party is 1-1 with a VEN (if it is a VEN), and if a VEN is 1-1 with a Resource, why do we need a ResourceID? Can a resource be moved to a different VEN? Can a Resource be transferred to a different Party? Is it because a Resource can be resold by an aggregator?
“You can’t have multiple Parties per customer”
So are all Wallmarts in North America identified as the same PartyID? If so, Registration is primarily concerns with identifying your PartyId.
tc
"It is the theory that decides what can be observed." - Albert Einstein
From: Holmberg, David [mailto:david.holmberg@nist.gov]
Sent: Wednesday, July 27, 2011 9:55 AM
To: Toby.Considine@gmail.com; 'Bartell, Bruce'; 'Ed Cazalet'; 'Koch, Edward'; energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Registration and Party IDs
Toby,
It seems you and EdC have a different perspective on Party. You seem to view it as equivalent to a resource, such that VEN is identified with a PartyID. EdC sees it as a customer with an account (or a customer with a SDP). This allows a Party to have multiple resources. Thus, a VEN has an associated PartyID, but a Party may have 0 to * Resources. Bill agrees with this, I think, or at least that a Party is not the same as a Resource. I think then that a Party is tied closely to a customer and you can’t have multiple Parties per customer. But a VEN and Resource are 1 to 1.
Interesting question about VTN/VEN, buyer/seller. I think a customer has a PartyID, and enters into market transactions to either buy or sell some resource. If selling, there should be an indication of that role, but not a SellerID, and there will be an associated ResourceID (for the generator or DR resource). If buying, there will be an indication of that role, and no associated ResourceID. A VEN should have an associated PartyID, SDP (meter mRID maybe, premise location?), and URL. Whether something is acting as VEN or VTN is maybe simply a role that is also indicated in a service exchange.
David
From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
Sent: Wednesday, July 27, 2011 9:10 AM
To: 'Bartell, Bruce'; 'Ed Cazalet'; Holmberg, David; 'Koch, Edward'; energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Registration and Party IDs
Slight change of pace here – into the schemas
We seem to be congealing around “Registration is how you get a Party ID”
A VEN is identified by a PartyID
A VTN is identified by a PartyID
A Transactive [agent] is identified by a PartyID
Several Parties may be part of some larger entity. If the Parties are acting as VENs, we may call that larger entity a Customer.
- A Customer is the business entity behind 1-to-many VENs that have a common relationship to the entity behind a VTN , each identified by a PartyID.
- Is there a common entity behind multiple VTNs that should have an ID as well?
- Is there a common entity behind multiple [agents] as well?
Parties have Roles: “Buyer” and “Seller”. Should we have a BuyerID and a SellerID instead of a CustomerID and “%%%”?
The eiParty is an existing type. The type consists of a partyID, a partyName, and a partyRole. Is this correct? Does it line up with the narrative above? If so, then it implies that a party enrolling as both a VTN and as a VEN should have two PartyIDs. This does not feel correct.
Where does the eiParty fit in the Transactive world?
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