OASIS Energy Interoperation TC

Here's a rough draft. This may well belong in section 3. Different business structures will typically drive different technical deployments. First, an actor, representing application code, may take on the Virtual End Node (VEN) role. The same application code may also support the Virtual Top Node (VTN) role. This is how the graph of VTNs and VENs in Figure 3-5 is constructed.  In that figure, actor G implements the role of VEN with respect to actor ;B, and the role of VTN with respect to actors I, J, and L. A Party interacts in transactive environments; the distinction is that a market may have many relationships. While it might seem attractive to make the actor that interacts with a market take on the VEN role (with the market taking on the VTN role), this is too restrictive. We can determine, view, and transact regardless of the VEN/VTN relationships that we have--and so the transactive interfaces use Party and CounterParty. Continuing with the VTN/VEN relationship, in a deployment one must make decisions about how the roles are selected, discovered, or assigned; this is out of scope of this specification. in contrast, a Resource is a thing, rather than an actor. A resource does not participate in relationships such as the actor/application interfaces in the figure. It would be easy to require that a Resource is related to (or possibly managed by ) exactly one actor.  That actor must be a VEN in the Energy Interoperation architecture. This would allow requests, reports, and other interactions to and from a single VEN which is uniquely related to that Resource. But other business cases would be simpler with potentially many Resources to a single VEN. In a transactive environment, that VEN may offer capabilities of its Resources to a market (as a Party), and without requiring a fine structure of collaborating VENs and VTNs. For example, a distributed application conforming to this specification MIGHT deploy in one of the following ways; (a) assign a single actor presenting the VEN role to each floor of a building, and a VTN related to them. For external interactions, that VTN for the building would present the VEN interface to receive and interact with the Energy Interoperation Services, and could present the Party role to tender, buy, and sell in a market, (b) assign a single actor presenting the VEN role to the building controller, and use other services to manage or convey information to the floor controllers (c) assign a single actor presenting the VEN role at the building controller, have that same actor present the VTN role to the individual floor controllers. The floor controllers present the VEN role to the building controller, while presenting the VTN role to its devices, each of which presents the VEN role to the floor controller. Clearly there are many deployments possible, including many not described here. Were we to require exactly one Resource to one VEN, these deployments would not be possible. Therefore, we make no requirement that a Resource be related to exactly one VEN, as this would make realistic deployments unnecessarily complex. ANOTHER SECTION - on roles An application finds, discovers, or is configured to use a particular Registrar. By using the EiREgisterParty service, that application obtains a PartyID. With that PartyID, the application can implement and interact using the Party Role in the Transactive Services. One thing that a Party may do is Enroll. The application may, when it has a PartyID and is identified, Enroll. There are a number of Enrollee Types, reflecting different business roles and enrollments, which are out of scope for this specification--only the names are defined, except in the case of a Resource which extends the emix Resource Description Type. The information required for Enrollment varies across Enroll Administrators--for example in North American wholesale markets on ISO will likely require different information or documentation than another. Since that information is out of scope, a deployment or profile would specify what information is required, and convey that information in an extension of the Enrollee types. Once Enrolled, a Party may have other capabilities, the definition and description of which is also out of scope.  The service operations supported are listed in SECTION FOR EiENROLL SERVICE.  The operations for Party Registration and Enrollment are designed, as are all other operations and data types, to be both extensible (with conventions described in SECTIONXXX) and evolvable over time to add new or extended functionality to future versions of Energy Interoperation, or by extension of information definitions in specific profiles. (FOOTNOTE? A series of brief Technical Notes is planned that will explain the process of defining profiles) Thanks! bill -- William Cox Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax

Bill, This is a good start on the discussion. First, you have introduced the idea that an actor represents "application code" that may take the role of a VEN and also support the VTN role. The term "application code "I think this is new to EI and not otherwise defined in EI except as hinted at in your "ANOTHER SECTION - on roles". It would be helpful to define it and make clear whether an actor must represent application code in VTN/VEN interactions and what the definition of "application code" as a concept is in EI. Second, you have stated that a Resource is a "Thing". I think a "Thing" is not otherwise defined in EI. Clearly in the case of a generator, it is a "Thing". But is a DR resource wherein a curtailment of possible usage by an end user is curtailed then also a "Thing"? Regarding your use cases for Resources, you correctly state that a Transactive Tender by a Party (say Calpine, an IPP) that owns multiple generation resources, for example, can issue a Tender to a CounterParty for an EMIX energy product, or a tender for an EMIX resource capability. Each tender for resource capability can identify the specific generation Resource, but in the case of the Tender for an EMIX Product, it can be a sale from Calpine's generation fleet. There is no need for the VTN/VEN concept in these interactions and so there is no need to state any relationship between a Resource and a VEN. With respect to your 3 distributed applications let me summarize them as follows: (a) Actor/VEN for each floor of building - Actor VTN for the building also acting as VEN outside building - no direct exposure of floor VENs outside of building VEN ( I assume). (b) Actor/VEN for the building - a building uses other services within building. (c) Same as (a) except that there is another level where the floor VEN is a VTN to the devices on the floor each of which is a VEN to the floor VTN. All of these are correct use cases, I think. Let me define in case (c) a device as a Resource, and a floor as an aggregate or Virtual Resource of the device resources on the floor. And let me define a building as aggregate or Virtual Resource of the floor Virtual Resources. If we associate a VEN with each device, and a VTN and VEN with the floor Virtual Resource and a VTN and VEN with the building we are still consistent with case (c). Case (a) uses other services below the floor level and case (b) uses other services below the building level, so these cases are subsets of case (a). There is another case (d) that is important here. In case (d) each floor is an actor/VEN/Resource and there is no building actor/VEN/Resource. In this case every floor is exposed as a Resource outside the building. There is also the case (e) of a portion of the building exposed as a VEN with some of the floors exposed as VENs to the outside. In all of these examples a VEN is associated with a Resource, but in some of them (transactive or other services in the building) there is no VEN to associate with a Resource. So I think the cases you have presented and the one I added all suggest that if a VEN exists it is associated with a single Resource or no Resource. There may be other use cases where a VEN is associated with multiple Resources but this is not yet demonstrated by these cases. With respect to your section on roles, I follow the process for an actor/application registering and obtaining a PartyID. I also follow the Enrollment process what I assume is enrollment in an EI/EMIX Market Context. In this description it is not clear whether enrollment is by Actors in the role of Party or VEN or VTN or what. Perhaps this is addressed in WD34. Ed 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: energyinterop@lists.oasis-open.org [ mailto:energyinterop@lists.oasis-open.org ] On Behalf Of William Cox Sent: Thursday, November 03, 2011 5:24 PM To: EITC Subject: [energyinterop] Draft text on resource/ven multiplicity - from EITC meeting November 2 Here's a rough draft. This may well belong in section 3. Different business structures will typically drive different technical deployments. First, an actor, representing application code, may take on the Virtual End Node (VEN) role. The same application code may also support the Virtual Top Node (VTN) role. This is how the graph of VTNs and VENs in Figure 3-5 is constructed. In that figure, actor G implements the role of VEN with respect to actor ;B, and the role of VTN with respect to actors I, J, and L. A Party interacts in transactive environments; the distinction is that a market may have many relationships. While it might seem attractive to make the actor that interacts with a market take on the VEN role (with the market taking on the VTN role), this is too restrictive. We can determine, view, and transact regardless of the VEN/VTN relationships that we have--and so the transactive interfaces use Party and CounterParty. Continuing with the VTN/VEN relationship, in a deployment one must make decisions about how the roles are selected, discovered, or assigned; this is out of scope of this specification. in contrast, a Resource is a thing, rather than an actor. A resource does not participate in relationships such as the actor/application interfaces in the figure. It would be easy to require that a Resource is related to (or possibly "managed by") exactly one actor. That actor must be a VEN in the Energy Interoperation architecture. This would allow requests, reports, and other interactions to and from a single VEN which is uniquely related to that Resource. But other business cases would be simpler with potentially many Resources to a single VEN. In a transactive environment, that VEN may offer capabilities of its Resources to a market (as a Party), and without requiring a fine structure of collaborating VENs and VTNs. For example, a distributed application conforming to this specification MIGHT deploy in one of the following ways; (a) assign a single actor presenting the VEN role to each floor of a building, and a VTN related to them. For external interactions, that VTN for the building would present the VEN interface to receive and interact with the Energy Interoperation Services, and could present the Party role to tender, buy, and sell in a market, (b) assign a single actor presenting the VEN role to the building controller, and use other services to manage or convey information to the floor controllers (c) assign a single actor presenting the VEN role at the building controller, have that same actor present the VTN role to the individual floor controllers. The floor controllers present the VEN role to the building controller, while presenting the VTN role to its devices, each of which presents the VEN role to the floor controller. Clearly there are many deployments possible, including many not described here. Were we to require exactly one Resource to one VEN, these deployments would not be possible. Therefore, we make no requirement that a Resource be related to exactly one VEN, as this would make realistic deployments unnecessarily complex. ANOTHER SECTION - on roles An application finds, discovers, or is configured to use a particular Registrar. By using the EiREgisterParty service, that application obtains a PartyID. With that PartyID, the application can implement and interact using the Party Role in the Transactive Services. One thing that a Party may do is Enroll. The application may, when it has a PartyID and is identified, Enroll. There are a number of Enrollee Types, reflecting different business roles and enrollments, which are out of scope for this specification--only the names are defined, except in the case of a Resource which extends the emix Resource Description Type. The information required for Enrollment varies across Enroll Administrators--for example in North American wholesale markets on ISO will likely require different information or documentation than another. Since that information is out of scope, a deployment or profile would specify what information is required, and convey that information in an extension of the Enrollee types. Once Enrolled, a Party may have other capabilities, the definition and description of which is also out of scope. The service operations supported are listed in SECTION FOR EiENROLL SERVICE. The operations for Party Registration and Enrollment are designed, as are all other operations and data types, to be both extensible (with conventions described in SECTIONXXX) and evolvable over time to add new or extended functionality to future versions of Energy Interoperation, or by extension of information definitions in specific profiles. (FOOTNOTE? A series of brief Technical Notes is planned that will explain the process of defining profiles) Thanks! bill -- William Cox Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax

William Cox Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 11/5/11 1:50 PM, Ed Cazalet wrote: Bill, This is a good start on the discussion. First, you have introduced the idea that an actor represents application code that may take the role of a VEN and also support the VTN role. The term application code I think this is new to EI and not otherwise defined in EI except as hinted at in your ANOTHER SECTION - on roles . It would be helpful to define it and make clear whether an actor must represent application code in VTN/VEN interactions and what the definition of application code as a concept is in EI. Second, you have stated that a Resource is a Thing . I think a Thing is not otherwise defined in EI. You're right...make that thing Clearly in the case of a generator, it is a Thing . But is a DR resource wherein a curtailment of possible usage by an end user is curtailed then also a Thing ? Yes. All resources partake of the same characteristics, with the description in emix:ResourceDescriptionType Regarding your use cases for Resources, you correctly state that a Transactive Tender by a Party (say Calpine, an IPP) that owns multiple generation resources, for example, can issue a Tender to a CounterParty for an EMIX energy product, or a tender for an EMIX resource capability. Each tender for resource capability can identify the specific generation Resource, but in the case of the Tender for an EMIX Product, it can be a sale from Calpine's generation fleet. There is no need for the VTN/VEN concept in these interactions and so there is no need to state any relationship between a Resource and a VEN. Correct. With respect to your 3 distributed applications let me summarize them as follows: (a) Actor/VEN for each floor of building - Actor VTN for the building also acting as VEN outside building - no direct exposure of floor VENs outside of building VEN ( I assume). Yes. (b) Actor/VEN for the building - a building uses other services within building. (c) Same as (a) except that there is another level where the floor VEN is a VTN to the devices on the floor each of which is a VEN to the floor VTN. All of these are correct use cases, I think. Let me define in case (c) a device as a Resource The problem is that you need to look both directions. A Resource MAY be related to a device or VEN in your examples, and a VEN MAY be related to one or more Resources. You can't use the transitivity of related to to then assert that there's exactly one VEN per Resource per VEN. Moreover, a building (which is a VEN in certain relationships) may bid many Resources. There's no hiding from the market (maybe that belongs on a a T-Shirt :-) ).  AND the resources may have nothing at all to do with the floors/etc that the building has. This all argues that the disconnection of market operations from VEN/VTN relationships requires the possibility of a configuration where there is more than one Resource per ACTOR. , and a floor as an aggregate or Virtual Resource of the device resources on the floor. And let me define a building as aggregate or Virtual Resource of the floor Virtual Resources. ...that could be bid into a market. If we associate a VEN with each device, and a VTN and VEN with the floor Virtual Resource and a VTN and VEN with the building we are still consistent with case (c). Case (a) uses other services below the floor level and case (b) uses other services below the building level, so these cases are subsets of case (a). There is another case (d) that is important here. In case (d) each floor is an actor/VEN/Resource and there is no building actor/VEN/Resource. In this case every floor is exposed as a Resource outside the building. The fundamental issue I have is that there is NOT a 1::1 relationship between VENs and Resources. We have to allow for that use case (in others in the list. Outside the building is fine. But the Resource is exposed to a market, and the VEN is exposed (in a given Market Context/program/etc) to a single VTN.  There must be a boundary/demarcation crossing - ties in with the ESI thread. There is also the case (e) of a portion of the building exposed as a VEN with some of the floors exposed as VENs to the outside. In all of these examples a VEN is associated with a Resource, but in some of them (transactive or other services in the building) there is no VEN to associate with a Resource. Again, many of the confusing discussions come from the latent assumption that there is EXACTLY one VEN per EXACTLY one Resource... So I think the cases you have presented and the one I added all suggest that if a VEN exists it is associated with a single Resource or no Resource. Disagree. in (a) the multiple Resources may be bid into a market by a single VEN.  Call it (a-prime). There may be other use cases where a VEN is associated with multiple Resources but this is not yet demonstrated by these cases. With respect to your section on roles, I follow the process for an actor/application registering and obtaining a PartyID. I also follow the Enrollment process what I assume is enrollment in an EI/EMIX Market Context. A Resource is enrolled. See the EnrolleeType classes, as in wd33. In this description it is not clear whether enrollment is by Actors in the role of Party or VEN or VTN or what. Perhaps this is addressed in WD34. Ed 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: energyinterop@lists.oasis-open.org [ mailto:energyinterop@lists.oasis-open.org ] On Behalf Of William Cox Sent: Thursday, November 03, 2011 5:24 PM To: EITC Subject: [energyinterop] Draft text on resource/ven multiplicity - from EITC meeting November 2 Here's a rough draft. This may well belong in section 3. Different business structures will typically drive different technical deployments. First, an actor, representing application code, may take on the Virtual End Node (VEN) role. The same application code may also support the Virtual Top Node (VTN) role. This is how the graph of VTNs and VENs in Figure 3-5 is constructed. In that figure, actor G implements the role of VEN with respect to actor ;B, and the role of VTN with respect to actors I, J, and L. A Party interacts in transactive environments; the distinction is that a market may have many relationships. While it might seem attractive to make the actor that interacts with a market take on the VEN role (with the market taking on the VTN role), this is too restrictive. We can determine, view, and transact regardless of the VEN/VTN relationships that we have--and so the transactive interfaces use Party and CounterParty. Continuing with the VTN/VEN relationship, in a deployment one must make decisions about how the roles are selected, discovered, or assigned; this is out of scope of this specification. in contrast, a Resource is a thing, rather than an actor. A resource does not participate in relationships such as the actor/application interfaces in the figure. It would be easy to require that a Resource is related to (or possibly managed by ) exactly one actor. That actor must be a VEN in the Energy Interoperation architecture. This would allow requests, reports, and other interactions to and from a single VEN which is uniquely related to that Resource. But other business cases would be simpler with potentially many Resources to a single VEN. In a transactive environment, that VEN may offer capabilities of its Resources to a market (as a Party), and without requiring a fine structure of collaborating VENs and VTNs. For example, a distributed application conforming to this specification MIGHT deploy in one of the following ways; (a) assign a single actor presenting the VEN role to each floor of a building, and a VTN related to them. For external interactions, that VTN for the building would present the VEN interface to receive and interact with the Energy Interoperation Services, and could present the Party role to tender, buy, and sell in a market, (b) assign a single actor presenting the VEN role to the building controller, and use other services to manage or convey information to the floor controllers (c) assign a single actor presenting the VEN role at the building controller, have that same actor present the VTN role to the individual floor controllers. The floor controllers present the VEN role to the building controller, while presenting the VTN role to its devices, each of which presents the VEN role to the floor controller. Clearly there are many deployments possible, including many not described here. Were we to require exactly one Resource to one VEN, these deployments would not be possible. Therefore, we make no requirement that a Resource be related to exactly one VEN, as this would make realistic deployments unnecessarily complex. ANOTHER SECTION - on roles An application finds, discovers, or is configured to use a particular Registrar. By using the EiREgisterParty service, that application obtains a PartyID. With that PartyID, the application can implement and interact using the Party Role in the Transactive Services. One thing that a Party may do is Enroll. The application may, when it has a PartyID and is identified, Enroll. There are a number of Enrollee Types, reflecting different business roles and enrollments, which are out of scope for this specification--only the names are defined, except in the case of a Resource which extends the emix Resource Description Type. The information required for Enrollment varies across Enroll Administrators--for example in North American wholesale markets on ISO will likely require different information or documentation than another. Since that information is out of scope, a deployment or profile would specify what information is required, and convey that information in an extension of the Enrollee types. Once Enrolled, a Party may have other capabilities, the definition and description of which is also out of scope. The service operations supported are listed in SECTION FOR EiENROLL SERVICE. The operations for Party Registration and Enrollment are designed, as are all other operations and data types, to be both extensible (with conventions described in SECTIONXXX) and evolvable over time to add new or extended functionality to future versions of Energy Interoperation, or by extension of information definitions in specific profiles. (FOOTNOTE? A series of brief Technical Notes is planned that will explain the process of defining profiles) Thanks! bill

Hi Bill, This is a good start! Other than the comments that Ed Cazalet mentioned (which I agree), I am having hard time grasping the conditions that an actor "may" take a role. Is it not true that an actor, if exist, "must" either take either/or VTN or VEN role? While you describe (accurately from my perspective) that "we make no requirement that a Resource be related to exactly one VEN." On a similar front we need to make sure that a resource (or whatever the term is now) that is an equivalent of "asset" from UCA requirements, be stated that more than one resource "may" relate to one VEN. Thanks, -Rish On Thu, Nov 3, 2011 at 5:23 PM, William Cox < wtcox@coxsoftwarearchitects.com > wrote: Here's a rough draft. This may well belong in section 3. Different business structures will typically drive different technical deployments. First, an actor, representing application code, may take on the Virtual End Node (VEN) role. The same application code may also support the Virtual Top Node (VTN) role. This is how the graph of VTNs and VENs in Figure 3-5 is constructed.  In that figure, actor G implements the role of VEN with respect to actor ;B, and the role of VTN with respect to actors I, J, and L. A Party interacts in transactive environments; the distinction is that a market may have many relationships. While it might seem attractive to make the actor that interacts with a market take on the VEN role (with the market taking on the VTN role), this is too restrictive. We can determine, view, and transact regardless of the VEN/VTN relationships that we have--and so the transactive interfaces use Party and CounterParty. Continuing with the VTN/VEN relationship, in a deployment one must make decisions about how the roles are selected, discovered, or assigned; this is out of scope of this specification. in contrast, a Resource is a thing, rather than an actor. A resource does not participate in relationships such as the actor/application interfaces in the figure. It would be easy to require that a Resource is related to (or possibly "managed by") exactly one actor.  That actor must be a VEN in the Energy Interoperation architecture. This would allow requests, reports, and other interactions to and from a single VEN which is uniquely related to that Resource. But other business cases would be simpler with potentially many Resources to a single VEN. In a transactive environment, that VEN may offer capabilities of its Resources to a market (as a Party), and without requiring a fine structure of collaborating VENs and VTNs. For example, a distributed application conforming to this specification MIGHT deploy in one of the following ways; (a) assign a single actor presenting the VEN role to each floor of a building, and a VTN related to them. For external interactions, that VTN for the building would present the VEN interface to receive and interact with the Energy Interoperation Services, and could present the Party role to tender, buy, and sell in a market, (b) assign a single actor presenting the VEN role to the building controller, and use other services to manage or convey information to the floor controllers (c) assign a single actor presenting the VEN role at the building controller, have that same actor present the VTN role to the individual floor controllers. The floor controllers present the VEN role to the building controller, while presenting the VTN role to its devices, each of which presents the VEN role to the floor controller. Clearly there are many deployments possible, including many not described here. Were we to require exactly one Resource to one VEN, these deployments would not be possible. Therefore, we make no requirement that a Resource be related to exactly one VEN, as this would make realistic deployments unnecessarily complex. ANOTHER SECTION - on roles An application finds, discovers, or is configured to use a particular Registrar. By using the EiREgisterParty service, that application obtains a PartyID. With that PartyID, the application can implement and interact using the Party Role in the Transactive Services. One thing that a Party may do is Enroll. The application may, when it has a PartyID and is identified, Enroll. There are a number of Enrollee Types, reflecting different business roles and enrollments, which are out of scope for this specification--only the names are defined, except in the case of a Resource which extends the emix Resource Description Type. The information required for Enrollment varies across Enroll Administrators--for example in North American wholesale markets on ISO will likely require different information or documentation than another. Since that information is out of scope, a deployment or profile would specify what information is required, and convey that information in an extension of the Enrollee types. Once Enrolled, a Party may have other capabilities, the definition and description of which is also out of scope.  The service operations supported are listed in SECTION FOR EiENROLL SERVICE.  The operations for Party Registration and Enrollment are designed, as are all other operations and data types, to be both extensible (with conventions described in SECTIONXXX) and evolvable over time to add new or extended functionality to future versions of Energy Interoperation, or by extension of information definitions in specific profiles. (FOOTNOTE? A series of brief Technical Notes is planned that will explain the process of defining profiles) Thanks! bill -- William Cox Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax -- Rish Ghatikar Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720 GGhatikar@lbl.gov +1 510.486.6768 +1 510.486.4089 [fax] This email is intended for the addressee only and may contain confidential information and should not be copied without permission. If you are not the intended recipient, please contact the sender as soon as possible and delete the email from computer[s].