OASIS Open Mailing List Archives  ·  All Lists  ·  energyinterop  ·  2009-12

energyinterop — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Groups - DR Programs (DR-Program-DRRC_20090914 SK edits.doc) uploaded












I’m not sure where this thread is going. Are people suggesting that we eliminate the simple DR information representations that are currently in the OpenADR specifcation?  I can certainly understand why some people would prefer not to use them which is why the current OpenADR specification does not dictate that they be used.  In my lifetime I've built and deployed numerous versions of embedded gateways and building management systems for precisely the type of utility applications we are trying to address in both the residential and C&I space. I've led development efforts where we spent millions of dollars engineering SOC's in order to bring down the BOM of such devices so that we could deploy them in massive quantities. My point is that I think I understand how important it is to support low cost intelligent controllers in buildings that communicate with a utility's headend in such a way that supports what Michel and Toby have described and I would never support a standard that does not support that model.  That being said, in terms of a standard, what is more important is that we recognize that there are a lot of different ways to skin a cat and we should support an exchange of information that supports options for how systems are deployed both now and in the future.

I’d like to reiterate that the simple representations in the OpenADR spec are sent in conjunction with and not instead of the other DR signal representations and it is not required that they be used.  There is nothing in the current OpenADR spec that precludes anyone from doing precisely what Michel and Toby have described with whatever type of device you might imagine regardless of the BOM.  What the alternate representations do allow is for a variety of approaches to be taken by the end user to consume DR signals and it is an option that is left open to the end user to decide.  If in fact people are suggesting that we eliminate those representations then in essence we will be narrowing the end user’s options and dictate to them that they consume the DR signals in a more constrained fashion than what is currently in the OpenADR spec. The bottom line is that given that there is overwhelming evidence in the current OpenADR deployments that the simplified representations are extremely useful for a wide variety of reasons I would not support eliminating them, especially since their presence does not preclude any of the various models I have seen described in this thread.

As suggested, lets add this as an agenda item for our next call.

-ed koch

From: Michel Kohanim [mailto:[email protected]]
Sent: Thursday, December 03, 2009 9:10 PM
To: [email protected]
Subject: RE: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914 SK edits.doc) uploaded

Hi Rish,

This is precisely what we are not saying: “super computer may solve all our computing problems”.

What we are saying is that almost any small footprint hardware/firmware solution can address OpenADR specs including WS Calendar.

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:[email protected]]
Sent: Thursday, December 03, 2009 7:23 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914 SK edits.doc) uploaded

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:

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
********************************


[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]