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