[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914 SK edits.doc) uploaded
As a specific example, I have an older product that has Python 2.3.
To my definition, a simple client is one that is less than 200 LOC in Python
2.3 and uses SGML parsing. I think a simple REST message is essential to low barrier to entry.
As seen on Twitter (forwarded more for humor more than serious consideration): Tim O'Reilly: @sramji in a meeting:
"The only reason you'd have only a SOAP API is because you hate 80% of
your addressable market." REST FTW. Regards, Dave Office: +1.651.407.4168 Mobile: +1.612.741.2759 Email: davidcwilson@trane.com -----Original Message----- As part of our research, LBNL interviewed programmers who wrote code to implement both smart clients (including control logic) and simple
clients (include a few integers, no logic). Research showed that programmers from multiple companies using a
variety of programming platforms could consistently take a pseudo code template
from LBNL, and create a simple software client application in less than one
hour. I interviewed four programmers that wrote "simple" software
client code to interface between their EMCS and the DRAS (circa 2005). The
answers to "time to complete task?" were: 1) 20 min. 2) 60 min. 3) 20
min. 4) less than 20 min. (not a measurable task). The same question was asked of five "smart client"
programmers that wrote code to interface between their EMCS and the "Price Server"
(circa 2003). Since they were required to include logic and other complexities the
task took from "weeks to months". To keep the technical and economic bar to entry as low as possible, we should keep the simple client (or equal) in the spec. -Dave Watson LBNL -----Original Message----- From: Michel Kohanim [mailto:michel@universal-devices.com] Sent: Friday, December 04, 2009 12:36 AM To: energyinterop@lists.oasis-open.org Subject: RE: RE: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914 SK edits.doc) uploaded Hi David, What device does the conversation from IP to contact closure? Can't the
same device support WS Calendar and Open ADR messages? If so, then there's
no need for the simplified messages. If not, then I would have to prove to
you that $20.00 devices can in fact do much more than what you can imagine. 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: David S. Watson [mailto:DWatson@lbl.gov] Sent: Friday, December 04, 2009 12:27 AM To: michel@universal-devices.com Cc: energyinterop@lists.oasis-open.org Subject: Re: RE: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914 SK edits.doc) uploaded The concept of the "simple" client evolved out of 7+ years of
Berkeley National Lab field tests in the C&I sector. Very early on we determined that the lack of a common, simple interface
to existing facilities buildings was a major barrier to recruitment and participation in automated DR programs. The simple client concept
has two critical features: 1) Well suited for contact closure (hardware interfaces) or gateway (software interfaces). 2) Allows ratepayer choice. They decide in advance what it means
for them to do a "medium" or "high" shed. They decide
whether or not to use the "event pending" (aka near or far) advanced alert signals to
pre-cool their facility. The most interoperable signal (by far) is dry contact closures. Every
EMCS of every vintage can read digital inputs. With no protocol
conversions necessary, one device (IP to contacts) will work for virtually all
sites. This reduces not only BOM costs, but enables a DR program to be
deployed to all customers with one simple interface device type. None of the aforementioned features are precluded when a subset of
customers use a more sophisticated interface. Research shows that only
10-20% of early adopters will have the capability to manage software gateway interfaces in the first few years. The general population of
existing commercial buildings will be even less adaptable. In summary: We recommend leaving the so called "simple"
client (or equal) in the standard, in addition to the "smart" client. Best regards, Dave Watson LBNL In automated DR tests in 2005, (15) sites were
recruited. Of these, (12) used simple clients and (3) used smart clients. The
introduction of the simple client enabled virtually any site to participate. It
removed barriers to recruitment. Automated Critical Peak Pricing Field Tests: Program Description and Results, M.A. Piette et al., Lawrence 2006 The concept of the simple client or other means to enable contact
closure interfaces to EMCS is imperative the wide-spread adoption of automated
DR. -Dave Watson LBNL ----- Original Message ----- From: Michel Kohanim <michel@universal-devices.com> Date: Thursday, December 3, 2009 11:14 pm Subject: RE: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded To: energyinterop@lists.oasis-open.org > Hi Ed, > > > > You make valid points. In short, what we are saying is this: > > 1. An agent (say DRAS) will
take the [potentially] > computationallyintensive 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 > interoperablemessage 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 > ANYTHINGbut 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_20090914SK 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 > intelligentcontrollers in buildings that communicate with a > utility's headend in such a > way that supports what Michel and Toby have described and I would > neversupport 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
> exchangeof 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 > nothingin 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 > simplifiedrepresentations 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_20090914SK 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/firmwaresolution 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_20090914SK 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 > simplybecause 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_20090914SK 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: > 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
> thatleave "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 > pricinggoals 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 > 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, > 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> > <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> > <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 > 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> > <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> > <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 > > > > > > Email: Toby.Considine@ unc.edu > > Phone: (919)962-9073 > > http://www.oasis-open.org > > blog: www.NewDaedalus.com <http://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> > <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 > > > GGhatikar@lbl.gov <mailto: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 > > > GGhatikar@lbl.gov | +1 510.486.6768 | +1 510.486.4089 [fax] > > > > This email is intended for the addressee only and may contain > confidentialinformation 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 --------------------------------------------------------------------- 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]