I second some of Rish’s comments and
would like to add another comment.
I agree that we need to keep an option for
simple clients to broaden the availability to retrofit solutions in the field.
My added point is that DR needs to include
a use case for building pre-cooling. In the residential segment, I think
customers accept raising the set point by a couple of degrees and letting the
house get “warm”.
Commercial customers are less willing to
tolerate a “warm” environment. But there is a greater
opportunity to pre-cool and use thermal storage. The DR needs to expand
past the “turn the generator on” model where advance notification
is ~ 30 minutes to 2 – 12 hours notice. Use cases for that should
be supported in a simple way.
I can see how a simple count down timer
would be of great help.
Dave
Office:
+1.651.407.4168
Mobile:
+1.612.741.2759
Email:
From: Girish Ghatikar [mailto:]
Sent: Wednesday, December 02, 2009
7:06 PM
To:
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:]
Sent: Wednesday, December 02, 2009
11:51 AM
To: Holmberg, David;
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:]
Sent: Wednesday, December 02, 2009
11:31 AM
To:
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:]
Sent: Wednesday, December 02, 2009 2:04 PM
To:
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:]
Sent: Wednesday, December 02, 2009 10:59 AM
To: ''
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
-----Original Message-----
From: Michel Kohanim [mailto:]
Sent: Wednesday, December 02, 2009 1:36 PM
To:
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
| +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
The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.
