[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914SK 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: 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 Does
this make sense? Thanks, -----Original
Message----- 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:
' 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
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]