[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914 SK edits.doc) uploaded
Bob, Thanks
so very much for the response. I must say that I am in full agreement with both
you and Toby. 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: Old, Bob [mailto:bob.old@siemens.com] I’ve
always thought the scope of EITC was far too wide, but it’s not my call.
However, I understand the desire to have one high level mechanism for
communicating DR signals (whatever they might be) to all consumers, C&I, as
well as Residential. Though
we talk about low power devices, the hardware guys have been helping us out in
the embedded processor industry. We’ve recently been using an ARM 32-bit
Cortex M3 in our lowest level controllers. I would expect to use one with
256k of Flash and 20k of SRAM for a residential ESI/Gateway (see attachment,
from the CEC doc here,)
if we got into the residential market for ESI’s. This class of
device has the right price point for a Residential product. It has plenty
of power for a minimal IP stack to the outside world, whatever in-home network
technology you want, and the Elliptic Curve Cryptography Public Key
Infrastructure the US utilities are currently demanding for Authentication,
Integrity and Confidentiality. And
I believe the Atmel 8-bit ATmega128L with only 128k Flash, 4k EE, and 4k SRAM
are being used by the utilities for their current Residential ESI product
rollouts. These do not support IP but do support the PKI stuff.
This class of device is the previous generation. So
I don’t see the minimum level of smartness of an ESI being so low as to
constrain our Energy Interop options in any way. And BMS/EMS/Meters are
PC class devices. Best, B.O.
December 3, 2009 Robert
Old Siemens
Industry, Inc. Building
Technologies 1000
Deerfield Pkwy. Buffalo
Grove, IL 60089-4513 Tel.:
+1 (847) 941-5623 Skype:
bobold2 bob.old@siemens.com www.siemens.com From: Michel
Kohanim [mailto:michel@universal-devices.com] 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] David,
Toby, and Michel: 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]
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] 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, -----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: '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 blog: 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 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
--
---------------------------------------------------------------------
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]