FW: [energyinterop] Groups - DR Programs (DR-Program-DRRC

Michel,

I don't think that how the simple levels are determined should be part of the standard and thus there is no need to include that as some sort of functional requirement of the entity sending the signals. They are just another representation of DR related information like price, or amount of shed, or percent shed or any of a number of specifications that might be sent as part of a DR signal that we should include in the standard. Including the possibility of sending simple levels does not dictate that the values are determined by any particular means, but it does open the possibility for those levels being determined in a number of different ways. In current implementations the simple levels are set by the utility based upon the inherent nature of the DR program while in other cases they are set by preferences sugmitted by the user. This is no different than other types of information like price for example. No one is suggesting that we specify how the price is set even though it might be determined by market conditions or perhaps by the user that sets it himself by submitting a bid. The simple shed levels are no different in that regard. We don't want to be in the business of specifying how the information that is sent as part of a DR signals is determined, but we do want to support as many forms of information as makes sense to support both the utility programs and the entities that need to consume those signals.

-ed koch

From: Michel Kohanim [michel@universal-devices.com]
Sent: Friday, December 04, 2009 2:13 AM
To: energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914 SK edits.doc) uploaded

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

********************************

From: Edward Koch [mailto:ed@akuacom.com]
Sent: Thursday, December 03, 2009 10:28 PM
To: energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] 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:michel@universal-devices.com]
Sent: Thursday, December 03, 2009 9:10 PM
To: energyinterop@lists.oasis-open.org
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:GGhatikar@lbl.gov]
Sent: Thursday, December 03, 2009 7:23 PM
To: michel@universal-devices.com
Cc: energyinterop@lists.oasis-open.org
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

********************************

-----Original Message-----

From: Girish Ghatikar [mailto:GGhatikar@lbl.gov]

Sent: Thursday, December 03, 2009 8:44 AM

To: michel@universal-devices.com

Cc: energyinterop@lists.oasis-open.org

Subject: Re: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914

SK edits.doc) uploaded

Michel,

It is my understanding that the scope issues to addressed by EI TC for

DR is beyond RTP. I am missing something?

Some sentences from the original EI TC charter purpose that might be

relevant and to revisit:

1. "The Technical Committee will define the interaction of Smart Grids

with their end nodes: Smart Buildings and Facilities, Enterprises,

Industry, Homes, and Vehicles. Dynamic pricing, reliability, and

emergency signals must be communicated through interoperability

mechanisms that meet business needs, scale, use a variety of

communication technologies, maintain security and privacy, and are

reliable."

2. "These specifications will define service interfaces and the data on

which they operate to allow interoperation without requiring deep

knowledge of the systems as they are implemented."

Thanks,

-Rish

Michel Kohanim wrote:

Hi Rish, welcome back!

1. I think we have to be a little careful with usage of words such as

"extensible and flexible" to define "simple". In other words, we better

come

up with concrete requirements to "define" what "simple" means. As of right

now - and based on what I've read so far - to me simple means "the usage

of

flags for devices that cannot compute anything above and beyond base 3"

2. If in the future OpenADR is going to define the communications

standards

for devices with an embedded ESI, then isn't WS Scheduling part of the

stack

of operations they must be able to support? If so, then where does that

leave "simple"?

Please do not get me wrong for I truly believe in simplicity. I would also

be very interested in all the research and any results thereof. My guess

is

that most of those results are a little antithetical to real-time pricing

goals and aspirations.

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: Girish Ghatikar [mailto:GGhatikar@lbl.gov]

Sent: Wednesday, December 02, 2009 8:13 PM

To: michel@universal-devices.com

Cc: energyinterop@lists.oasis-open.org

Subject: Re: [energyinterop] Groups - DR Programs

(DR-Program-DRRC_20090914

SK edits.doc) uploaded

Michel,

Yes, it's been a long time - I was on travel for last few weeks.

1. You're right that there will always be devices with low processing

power or capabilities to interpret the rich logic and also from cost

point of view this seem plausible. I am not saying that that these

devices do exist for certain in future, however, our standards should be

extensible and flexible enough to handle such requirements. Again, this

is not the only reason why the simple information makes sense.

2. What you understand is correct and it's outside of this scope (and

always has been for OpenADR development) of the communication between

BAS/EMS/ESI/Meter/Gateway and end devices. However, we can foresee that

in future, that the OpenADR can directly communicate with the devices

(where ESI is integral part of the device itself.

Another thing I didn't include in my earlier note was an example of

recently conducted PLP pilot where the existing CPP DR program customers

were switched without any reprogramming to their controls or strategies

although the original CPP was sending price multipliers and the PLP sent

the go to dispatch levels. The use of simple levels from simple

information made this possible.

Thanks,

-Rish

Michel Kohanim wrote:

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]

*Sent:* Wednesday, December 02, 2009 5:06 PM

*To:* energyinterop@lists.oasis-open.org

*Subject:* Re: [energyinterop] Groups - DR Programs

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

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:ed@akuacom.com]

*Sent:* Wednesday, December 02, 2009 11:51 AM

*To:* Holmberg, David; energyinterop@lists.oasis-open.org

<mailto:energyinterop@lists.oasis-open.org>

*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:david.holmberg@nist.gov]

*Sent:* Wednesday, December 02, 2009 11:31 AM

*To:* energyinterop@lists.oasis-open.org

<mailto:energyinterop@lists.oasis-open.org>

*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:michel@universal-devices.com]

Sent: Wednesday, December 02, 2009 2:04 PM

To: energyinterop@lists.oasis-open.org

<mailto:energyinterop@lists.oasis-open.org>

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:Toby.Considine@unc.edu]

Sent: Wednesday, December 02, 2009 10:59 AM

To: 'energyinterop@lists.oasis-open.org

<mailto: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

http://www.oasis-open.org

blog: www.NewDaedalus.com <http://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

<mailto: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

--

Rish Ghatikar

Lawrence Berkeley National Laboratory

1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720

GGhatikar@lbl.gov <mailto:GGhatikar@lbl.gov> | +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].

---------------------------------------------------------------------

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
GGhatikar@lbl.gov | +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].

energyinterop message