Michel,
I agree that RTP would simplify many problems that are barrier to DR
participation. However, implementation of systems and other related
actions (e.g., programming costs) for this requires understanding
buildings, strategies, and the systems that exist currently (with or
without retrofits) and those that may come in future. It also requires
customer adoption and migration, which takes time. We can say a super
computer may solve all our computing problems, however, the key
question here is -- can everyone afford it and if they can, what would
it cost to operate and maintain it?
Thank you,
-Rish
Michel Kohanim wrote:
086f01ca7488$b01d3980$1057ac80$@com" type="cite">
Hi Rish,
No, you are not missing something. What I was trying to say was:
If simplicity is the result of all the research in DR, then - in all
likelihood - those results would be a little antithetical to RTP simply
because RTP is anything but simple (with multiple actors and 10s of
intertwined use cases).
With kind regards,
********************************
Michel Kohanim, C.E.O
Universal Devices, Inc.
(p) 818.631.0333
(f) 818.436.0702
http://www.universal-devices.com
********************************
-----Original Message-----
From: Girish Ghatikar [mailto:GGhatikar@lbl.gov]
Sent: Thursday, December 03, 2009 8:44 AM
To: michel@universal-devices.com
Cc: energyinterop@lists.oasis-open.org
Subject: Re: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914
SK edits.doc) uploaded
Michel,
It is my understanding that the scope issues to addressed by EI TC for
DR is beyond RTP. I am missing something?
Some sentences from the original EI TC charter purpose that might be
relevant and to revisit:
1. "The Technical Committee will define the interaction of Smart Grids
with their end nodes: Smart Buildings and Facilities, Enterprises,
Industry, Homes, and Vehicles. Dynamic pricing, reliability, and
emergency signals must be communicated through interoperability
mechanisms that meet business needs, scale, use a variety of
communication technologies, maintain security and privacy, and are
reliable."
2. "These specifications will define service interfaces and the data on
which they operate to allow interoperation without requiring deep
knowledge of the systems as they are implemented."
Thanks,
-Rish
Michel Kohanim wrote:
Hi Rish, welcome back!
1. I think we have to be a little careful with usage of words such as
"extensible and flexible" to define "simple". In other words, we better
come
up with concrete requirements to "define" what "simple" means. As of right
now - and based on what I've read so far - to me simple means "the usage
of
flags for devices that cannot compute anything above and beyond base 3"
2. If in the future OpenADR is going to define the communications
standards
for devices with an embedded ESI, then isn't WS Scheduling part of the
stack
of operations they must be able to support? If so, then where does that
leave "simple"?
Please do not get me wrong for I truly believe in simplicity. I would also
be very interested in all the research and any results thereof. My guess
is
that most of those results are a little antithetical to real-time pricing
goals and aspirations.
With kind regards,
********************************
Michel Kohanim, C.E.O
Universal Devices, Inc.
(p) 818.631.0333
(f) 818.436.0702
http://www.universal-devices.com
********************************
-----Original Message-----
From: Girish Ghatikar [mailto:GGhatikar@lbl.gov]
Sent: Wednesday, December 02, 2009 8:13 PM
To: michel@universal-devices.com
Cc: energyinterop@lists.oasis-open.org
Subject: Re: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914
SK edits.doc) uploaded
Michel,
Yes, it's been a long time - I was on travel for last few weeks.
1. You're right that there will always be devices with low processing
power or capabilities to interpret the rich logic and also from cost
point of view this seem plausible. I am not saying that that these
devices do exist for certain in future, however, our standards should be
extensible and flexible enough to handle such requirements. Again, this
is not the only reason why the simple information makes sense.
2. What you understand is correct and it's outside of this scope (and
always has been for OpenADR development) of the communication between
BAS/EMS/ESI/Meter/Gateway and end devices. However, we can foresee that
in future, that the OpenADR can directly communicate with the devices
(where ESI is integral part of the device itself.
Another thing I didn't include in my earlier note was an example of
recently conducted PLP pilot where the existing CPP DR program customers
were switched without any reprogramming to their controls or strategies
although the original CPP was sending price multipliers and the PLP sent
the go to dispatch levels. The use of simple levels from simple
information made this possible.
Thanks,
-Rish
Michel Kohanim wrote:
Hi Rish, long time no see!
1. You are saying that: there are and shall be devices/systems with
low processing power and therefore we should support simple messages.
Yes?
2. Are HAN/Building communications within the jurisdiction of this
taskforce? i.e. are we going to discuss how
BAS/EMS/ESI/Meter/Gateway/? communicate with end devices? As far as I
know, this is not the case unless the mandate has changed. If no, then
we have to decide what constitutes the minimum level of "smartness"
for a BAS/ESI/EMS
With kind regards,
********************************
Michel Kohanim, C.E.O
Universal Devices, Inc.
(p) 818.631.0333
(f) 818.436.0702
http://www.universal-devices.com
********************************
*From:* Girish Ghatikar [mailto:GGhatikar@lbl.gov]
*Sent:* Wednesday, December 02, 2009 5:06 PM
*To:* energyinterop@lists.oasis-open.org
*Subject:* Re: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded
David, Toby, and Michel:
The purpose of using the terms simple and smart client extends beyond
the purposes of its use within legacy systems or messages such as
"FAR, NEAR, etc." This could be up to local utility to define the
precise interpretation for the customers. I think this should be
looked from the perspective of the DR information (e.g.,
reliability/emergency or price) that is sent to the devices, which
could come in many forms. This concept of simple vs. smart information
(client names are indicative of what information is eventually used at
end uses) is very important and the need has originated from years of
research, field tests, and commercial programs. For me, it doesn't
matter if it's called by some other name, the information is the key.
The idea here is not just to be supportive of legacy or less
sophisticated systems. It's also to make OpenADR extensible and
scalable to smaller devices and sectors such as small commercial and
residential, allow innovation and let systems interoperate and offer
scalable solutions such as the concept of "bridge client" that we used
within FM/RDS technology demonstration recently (translating OpenADR
smart information of hourly prices into simple information of tiers
and modes that PCTs could easily understand). In particular, I would
like to emphasize:
*1. Legacy Systems:* While I partially agree to Toby's comment, "Our
work should be informed by legacy systems, but not limited or dictated
by them...," there is also a need to understand to what end-use
devices are we sending this information? The topic of contention in
most of the Smart Grid workshops has been -- how do we address
interoperability and standards with existing installed base? I think
it's obvious that we should not ignore it.
*2. Less sophisticated clients: *We should make sure that the existing
or future devices have the ability to participate in DR programs with
lesser processing power (over logical translation of smart information
locally), which by themselves are not cost prohibitive (more
processing and logic = higher device costs). This is also true of even
sophisticated EMCS (with processing power) that would like to make use
of simple information to eliminate programming and maintenance costs
as they're tied to end-use strategies. This it's apparent that the
end-use strategies and those need simple mode information (e.g.,
NORMAL/MODERATE/HIGH). Of course any processing and mapping of smart
information could be derived by a middleware (e.g., DRAS in our case,
which could be something else such as bridge client)
*3. Extensibility and scalability to low processing devices* -
Understandably our current focus is on Commercial and Industrial
(CnI). However, in future we may also see the results of the data
models from this TC work getting extended to end-use devises itself
(e.g., lighting ballasts, appliances, etc.) and also become part of
other standards (e.g., SEP 2.0) and extend to other sectors (e.g,
residential and small commercial).
*4. Allowing innovation and technology interoperability and
information standardization* - Simple information allows us to cross
boundaries and innovate that traditional communication and/or
technologies don't let us to. How will the end-use devices interpret
messages if we don't standardize these messages? An example was bridge
client that although used smart information (e.g., day-ahead hourly
prices), the ability of standardization of simple information allowed
them to translate and transmit the same message in simple form (the
protocol translation from TCP/IP to FM/RDS messages was a specific
implementation for this bridge client) to PCTs due to bandwidth and
payload issues. In future, these same PCTs could also directly listen
to OpenADR simple information directly or through third-party and
interoperate with communication protocols and technologies without any
change in programming or strategies.
This is a long way of saying that the concept of simple and smart
information is very important if we're designing the smart grid for DR
that is useful for not just the current systems, however, also for
likely future changes.
If needed, I or someone here at LBNL can send more information on
field tests reports that cover the topics of smart vs. simple clients.
Thanks!
-Rish
Michel Kohanim wrote:
Hi Ed,
I would like to agree with you but having been involved in many legacy
integration projects makes me a little wary of leaving
constructs/vocabulary/nouns (or however you refer to them) open for
interpretation. You could obviously talk about user preferences,
criteria by which they are constrained, and where they should be
stored/exectuted (DRAS, Portal, EMS, end device, etc.). This said,
however - and in my view - system-to-system messages should not be
open to interpretation especially if they are subjective like Far and
Near.
With kind regards,
********************************
Michel Kohanim, C.E.O
Universal Devices, Inc.
(p) 818.631.0333
(f) 818.436.0702
http://www.universal-devices.com
********************************
*From:* Edward Koch [mailto:ed@akuacom.com]
*Sent:* Wednesday, December 02, 2009 11:51 AM
*To:* Holmberg, David; energyinterop@lists.oasis-open.org
<mailto:energyinterop@lists.oasis-open.org>
*Subject:* RE: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded
David,
What you are saying makes perfect sense, although I would not classify
the simple signal representations of OpenADR as DLC. It really is
nothing more than a more simplified representation of the DR
information that is sent in conjunction with (NOT instead of) any
other DR related information such as prices.
The discussion started around the state variables in the OpenADR
message and then transformed into whether we should support legacy
systems. It's important that we not conflate those two issues too much
because while the vocabulary used to define the simple state variables
in the OpenADR message is driven by a desire to support legacy systems
the requirement to have an alternative vocabulary whose semantics can
be defined by the user for expressing DR event information is actually
a bigger question and is in fact anything but legacy in its
applicability and power. Having the option of an alternative
representation, especially if it can be defined and controlled by the
end user, does not dictate that it be used by the end user. If they
want to buy a new intelligent gateway in which to embed all the
intelligence there then so be it. I think that is a fine way of
automating DR, but it should not be the only one. The key is in having
options the end user can choose from that allow for easier integration
and consumption of DR signals in a fashion that makes the most sense
for the end user. The current mechanism in OpenADR provides great
flexibility in distributing intelligence and has proven its worth in
the currently deployed systems. Having alternative representations of
the DR information allows for the end user to decide between those
different representations AND allows for the translation between those
different representations to occur at different points in the
architecture. Could occur in the head end or it could occur in the
facility, or there may not be any translation at all. I can tell you
that current OpenADR implementations take advantage of all three of
those scenarios depending upon the needs of the end user. The
alternative is to restrict end user's options and force them to
consume information in a particular way which if the decision is to
explicitly NOT support legacy systems will result in a standard that
requires huge investments in new infrastructure instead of the clean
migration path via the options that OpenADR was designed to provide.
-ed koch
------------------------------------------------------------------------
*From:* Holmberg, David [mailto:david.holmberg@nist.gov]
*Sent:* Wednesday, December 02, 2009 11:31 AM
*To:* energyinterop@lists.oasis-open.org
<mailto:energyinterop@lists.oasis-open.org>
*Subject:* RE: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded
OpenADR defines an architecture with a DRAS server in the cloud. The
DRAS server can send rich info to the smart DRAS client, or more
DLC-like info (I may be off base here, please correct) to the simple
clients. The simple client can't think so well, so the server does
more thinking and directing. It seems there is a full spectrum of
communications that span the collaborative pure price approach to the
"shut off the water heater" DLC approach.
We are defining the information and messages for energy interoperation
at the facility interface (no?). We have said that we would include
the CA DR program messages that form the meat of OpenADR--that is, "go
to level 2, start time, duration". We are not specifying how to talk
to a specific device to make it act in a certain way, as is the case
for SEP--we are not defining messages for raising the set-point temp,
shutting off the water heater, etc. That is, such commands are DLC,
and the EMS handles that (even if, as in the case of AMI, the EMS is
in the utility backend system). So, EIX (Energy Info eXchange
protocol) will not compete with SEP for DLC, although SEP has price
communications. A utility can keep the current "SEP from the back-end"
approach, or stick an ESI on the building that understands EIX
messages and then translates that to SEP commands (assuming that is in
use on the HAN).
Does this make sense?
Thanks,
David
-----Original Message-----
From: Michel Kohanim [mailto:michel@universal-devices.com]
Sent: Wednesday, December 02, 2009 2:04 PM
To: energyinterop@lists.oasis-open.org
<mailto:energyinterop@lists.oasis-open.org>
Subject: RE: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded
Thanks Toby. I totally agree.
With kind regards,
********************************
Michel Kohanim, C.E.O
Universal Devices, Inc.
(p) 818.631.0333
(f) 818.436.0702
http://www.universal-devices.com
********************************
-----Original Message-----
From: Considine, Toby (Campus Services IT)
[mailto:Toby.Considine@unc.edu]
Sent: Wednesday, December 02, 2009 10:59 AM
To: 'energyinterop@lists.oasis-open.org
<mailto:energyinterop@lists.oasis-open.org>'
Subject: RE: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded
I think the simple answer is no. Legacy systems work with legacy
communications. Some people will have a temporary business of putting
shims on old systems, whether they worked with OpenADR, or with SEP
1.0, or even with a 3rd party such as ENERNOC.
Our work should be informed by legacy systems, but not limited or
dictated by them...
tc
"A man should never be ashamed to own that he has been in the wrong,
which is but saying ... that he is wiser today than yesterday." --
Jonathan Swift
Toby Considine
Chair, OASIS oBIX TC
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
blog: www.NewDaedalus.com <http://www.NewDaedalus.com>
-----Original Message-----
From: Michel Kohanim [mailto:michel@universal-devices.com]
Sent: Wednesday, December 02, 2009 1:36 PM
To: energyinterop@lists.oasis-open.org
<mailto:energyinterop@lists.oasis-open.org>
Subject: RE: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded
Hi Sila, thanks. That makes perfect sense.
The next question is the scope of our efforts: do we foresee
supporting vintage systems?
With kind regards,
********************************
Michel Kohanim, C.E.O
Universal Devices, Inc.
(p) 818.631.0333
(f) 818.436.0702
http://www.universal-devices.com
********************************
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Rish Ghatikar
Lawrence Berkeley National Laboratory
1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
GGhatikar@lbl.gov <mailto: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].
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
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]. |
|