[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Energy Interop Resources
|
Team: I agree with Ed. I think we have our
own term, VEN, and probably don’t need to re-define another one that may
be concurrently used in other contexts. As Ann noted, there are only so many
words available. But we have defined our own term, the VEN, and perhaps just
need to define it relative to it’s meaning in our context. As Ed noted, we are managing the ENERGY of
a resource not the resource itself. The problem surfaces when someone wants
to think of the VEN as representing a physical device instead of the energy of
the resource or set of resources. A one-to-one relationship cannot be
force-fit into this modern system architecture, thus the VIRTUAL part of the End
Node (VEN). I think of my personal computer as a
single machine. The fact that it is a quad-core system with a
multitasking architecture behind the scenes is largely out of my view. I
may think in terms of activating one task or program. But it may spawn several
threads to complete the task by doing several things concurrently (e.g. recalculating,
spell-checking, going on line to check for newer version, etc) behind the
scenes. That multi-tasking is out of my vision and I have become
accustomed to this and my PC would be less capable if we forced it back to a
one-to-one mentality. When I call my wife on the phone, I don’t
call a specific serial number on a specific hardware platform, I dial the same
phone number as I always have for the past three generations of phone
technology and did not change the number (or area code) when we moved 675 miles
into a different area code. You could say it’s a virtual communication
device node as it could be forwarded (without my knowledge) to a different
number. The point to my retorhic and rambling is
that I suspect that someone who still needs to associate a VEN with a physical
device and/or identify the physical device to a level above the VEN (e.g. to
the VTN) may not not fully grasp the power, flexibility, and scalability of the
virtual REC/VEN (VTN/VEN) concept architecture. Perhaps we need to
re-focus on our level of understanding of the virtual concept which could be
the root of our definition problems. Sorry about the lecture. But I have
heard concerns from members of this group about loosing the advantages of the
virtual architecture and slipping back into a command and control form of
thinking. Gale Gale R.
Horst Electric
Power Research Institute (EPRI) From: Ed Cazalet
[mailto:ed@cazalet.com] In Gale’s original paper a VEN is
a Resource. We can call it a VEN but it is a Resource in my view. I see
no problem with that. Gale’s original paper also makes
the point that because of the intelligence that can now be built into
VEN/Resources, the interactions with a Resource and its VTN (was a REC ,
resource energy controller in his paper) now can be less about control and more
about interacting between the Resource and the VTN to manage the
“energy” from the resource rather than direct control of the
resource. Again here is a clear distinction
between the Resource and the Energy product it can produce or consume. Edward G. Cazalet, Ph.D. 650-949-5274 cell: 408-621-2772 From: I think most of this is on track. > Toby as you noted, resources below
a VTN may be an issue. It would seem that if a resource needs to be
addressed in any direct way from a VTN, that VEN resource should communicate
directly to that VTN. Otherwise it is an abstracted resource and is not
identifiable at the higher level. > We are looking for a word, that MAY
be “resource” for these things. We
could stick with consistent terminology and call it a “node” or
“electricity node” that refers to a communicating entity that
represents a device, devices, or system that consumes or produces
electricity. I suppose it would be easier to call it a resource, if that
term had not already been over-used and confuscated. ;) > 51 – is # 4 in a list which,
as stated in 52, “is outside the scope…”
referring to “4. Demographic information about the people
represented by each VEN.” Toby,
this is probably a minor point. But my point was not whether this is out
of scope, that is a given fact. But the mere mention of communicating
information about people could bring fear, uncertainty, and doubt to some
readers. I was questioning why we would want to mention this at
all. The very architecture itself already leaves this out of scope. Gale R.
Horst Electric
Power Research Institute (EPRI) From: Considine, Toby
(Campus Services IT) [mailto:Toby.Considine@unc.edu] Some observations as I read these
comments. Your first addition “inside the
microgrid”, is correct. Resources below a VTN were added into
conversations about a month ago. Until then there was, as you say, noting
within / beyond a VTN Last Wednesday, it was posited that
[Target] might have a Resource for each start in the metro area…this
makes me a little uneasy, but I haven’t been able to define it all away. 51 – is # 4 in a list which, as
stated in 52, “is outside the scope…” I agree with your summary of 52-57. I am
attempting to expose the fuzziness around the use of the non-normatively
defined (yet) word resource…. If I use EI to interoperate between
ISO and Aggregators, these resources may be industrial sites or classes of
customers, or class of equipment pooled across many customers. If I use EI to interoperate
between Aggregator and Industrial Site, these resources may be buildings (on
the site), industrial processes, collections of equipment, or an individual big
system. If I use EI to interoperate with
the home, these resources may be the water heater, all the gaming systems in
the building, or some sort of generic comfort system. We are looking for a word, that MAY be
“resource” for these things. tc "It is the theory
that decides what can be observed." - Albert Einstein
From: Toby: I believe I agree with lines 6-7 and 11-12
but this description leaves it a bit fuzzy in my mind. Did you intend to
say “EI is recursive, in that a VEN MAY be the interface to a microgrid
that is itself managed by the VTN-VEN interactions of EI; in that internal
market, the
system which exposes a VEN interface to the outside world may expose a VTN
interface inside the microgrid.” Line 29-30, I never thought of registering
a product that cannot ever be turned off, such as medical equipment in this
example. Interesting thought … but I suppose possible? This
could provide a decent and automated way to locate and manage the existence of
these devices. (Could require certification by some medical organization
as qualifying as this type of device.) Line 38, I would view a VEN as a single
resource in the logical scheme of things (thus the word “Virtual” in VEN). If it
“withdraws a resource”, I think what you mean is that it changes
the amount of resources (e.g. energy) available. This may or may not be
any change (e.g. withdrawal) of a physical resource. In other words it
could represent a variable resource and this is a key part of the concept
enabling it to change the amount currently available. (EPRI whitepaper mentions
this on page 5). In the example in line 46 in list item 1,
I would submit that although I agree that nameplate information for exact
identification of assets behind each resource is definitely not supported, it
may seem reasonable that a VEN report a minimal set of categories of its
resource. In other words if a VEN is representing a renewable energy
resource, that should be known as that may be a key qualifier for a program in
which the VTN is participating. (As noted in the bullet list on page 5 of
the EPRI whitepaper) Line 47-48 is an interesting one. It
would seem that the VTN needs to at least know where the VEN resources impact
the grid. Do we intend to limit this to only the grid and not be a
specification that supports distribution systems? It would seem that an
instance of the system utilizing EI spec could exist in either case. But
perhaps there was additional discussion around this item that I may have
missed? Line 49-50 seems OK noting that the VTN to
VEN can be one-to-many (or conversely VEN to VTN is one-to-one) the mentioned
audit information should not be needed. Line 51 – did we really need to say
this? Where do we become entangled with information about people to
where we need to broach this topic? I’m a bit confused about the last
paragraph (line 52-57). It seems to negate some of the earlier
paragraphs. Also, how do we “support this requirement, but …
not include…” (line 53-54) Gale Gale R.
Horst Electric
Power Research Institute (EPRI) From: Considine, Toby
(Campus Services IT) [mailto:Toby.Considine@unc.edu] As
requested, a preliminary write-up of our Resource discussions. For comments,
please use the numbered PDF. Thanks tc Energy Interop Resources 1 (which may, as Ed
Cazalet suggested, be misnamed) 2 As defined in the EPRI white paper, all interaction
is between the VEN and the VTN. Neither the VEN or 3 the VTN can interact
through the other or see past the other. EI is symmetric, in that a given
VTN-VEN 4 pair could swap rules for a different market interaction. EI is
recursive, in that a VEN MAY be the 5 interface to a microgrid that is itself
managed by the VTN-VEN interactions of EI; in that internal market 6 the system
which exposes a VEN interface to the outside world may expose a VTN interface.
7 The inner workings of the “internal”
microgrid might be by BACnet, or by LONTalk, or by OPC, or by SEP, 8 or by KNX,
or by any mix of open and proprietary protocols. The “internal”
microgrid might be a 9 municipal utility, an office park, or an industrial site
that manages its internal energy using Energy 10 Interoperation. Whatever the
communications and interactions of the internal grid, the direct 11
interactions through the exterior-facing VEN are the same: none. 12 Resources as
Distinguishable Products 13 During enrollment, a VEN may choose to register one
or more products with the VTN. These products 14 are known as Resources. The
VTN has no direct interaction with these resources. As in a restaurant, 15
wherein the customer may request published menu items from the waitress, the
VTN may transact for 16 published resources from the VEN. Just as the customer
is not allowed to fetch food from the kitchen, 17 nor to order off menu meals,
so the VTN is not able to interact directly with the systems that underlie 18
each resource, or to request resources that are not registered. 19 The products represented by the resources may be
distinguished by any number of characteristics. EMIX 20 product definitions are
distinguished by attributes that include schedule, location, and source and 21
responsiveness. Investopedia defines product differentiation thus: 22 It may be as
simple as packaging the goods in a creative way, or as elaborate as
incorporating 23 new functional features. Sometimes differentiation does not involve
changing the product at all, 24 but
creating a new advertising campaign or other sales promotions instead. 25
The products represented by EI Resources may be as
concrete as an industrial stone crusher or as 26 abstract as an
aggregator’s product, “Air Conditioning for the Elderly”. A
Resource may be able to 27 respond both up and down, as can a domestic water
heater, or have unidirectional gradations of 28 response, as might a
thermostat. A VEN may even wish to register Resources for which no response is
29 possible, say, at-home medical equipment. 30 EI makes no assertion as to what might distinguish
two products or as to why different resources are 31 registered by the same
VEN. EI does not require that all load controlled by a VEN be indicated in 32
resources. There may be market rules that require such “full
registration” for all participants, but EI does 33 not. 34 Enrollment and Withdrawal of Resources 35 A VEN MAY choose to enroll a single Resource, and
reveal no information about its internal systems. 36 A VEN may have no Resources. Some markets may
require that all participants Enroll, even if they are 37 able to provide no
resources. A VEN may enroll new Resources and withdraw other Resources. Having
38 withdrawn its Resources, a VEN may again have no enrolled Resources. A VEN
with no Resources is 39 unable to participate in VEN-VTN based markets. It is
not in scope to define the market rules for VENs 40 without Resources 41 Ancillary Reporting
Requirements 42 Some markets may have reporting requirements beyond
those defined in Energy Interoperation. Energy 43 Interoperation neither
requires these requirements, nor supports them. Examples of such requirements
44 discussed in the Committee include: 45 1. Nameplate
information for exact identification of assets behind each Resource 46 2. Location
information to identify local distribution effects of Resources exposed by a
single VEN 47 that are distributed geographically (if allowed). 48 3. Customer
information to enable a third party to audit the market and determine if a
single 49 Resources is being sold multiple times 50 4. Demographic information about the people
represented by each VEN. 51 All such information is outside the scope of Energy
Interoperation. To the extent that participant 52 business rules or market
rules requires this information, Energy Interoperation will support this 53
requirement, but it will not include or enforce these requirements. (Perhaps this means that we need to 54 have an approval status on each Resource: Pending,
Approved, Refused. Perhaps only Resources 55 approved by the VTN can come to market. If so, that
Approval is out of scope; it is merely a reflection of 56 an out-of-band Enrollment.) 57 58 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]