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



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


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