Hi Ed,
You make valid points. In short, what we are saying is this:
1.
An agent (say DRAS) will take the [potentially] computationally intensive WS Calendar/Open ADR structures/operations and sends simple
load control/price messages depending on [some] preferences as defined by one or more actors
2.
Systems than can natively process WS Calendar/Open ADR messages, can ignore messages in 1
To me, #1 is functional requirements for a DRAS (or whatever we call it). i.e. DRAS shall allow [a predefined set of] actors to set preferences and constraints
on message semantics based on certain scheduling, price, and load control conditions. If DRAS will also participate in all DER activity, and If this taskforce is tasked with defining requirements for a DRAS, and if all agree that above is one of the requirements
then I have absolutely no problem whatsoever.
On the other hand, if this taskforce is tasked with defining
interoperable message structures then I would have problems with leaving the message semantics open to interpretation. The reason is quite simple: although everything would work fine in the case of one to many mapping between the utility and the consumer,
in the case of many to many (distributed M2M and DER) mapping between many actors, the interpreted semantics will be ANYTHING but interoperable. One would then have to find a mapping between a “Far” for me and a “Far” for you especially if there is a device
in the mix that can natively understand/process WS Calendar and Open ADR messages.
With kind regards,
********************************
Michel Kohanim, C.E.O
Universal Devices, Inc.
(p) 818.631.0333
(f) 818.436.0702
http://www.universal-devices.com
********************************
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
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
********************************
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
********************************