OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [energyinterop] Draft text on resource/ven multiplicity - from EITC meeting November 2


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].


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]