RE: RE: [energyinterop] Groups - DR Programs(DR-Program-DRRC_20090914 SK edits.doc) uploaded

["Considine, Toby (Campus Services IT)" <Toby.Considine@unc.edu>]

B.O. ++1

Security and guaranteed delivery and transactional behaviors re all reasons that REST, which is superb in the test bed, is not superb in the third party millions of clients, these are business transactions environment. REST is the preferred environment of the prototype because prototypes do not require mature transactions, mature security. And anyone who replies "Security? We've got HTTPS" is not in the game, yet.

We should not fork the standard. Why decide that every client must be registered with [the utility] as to whether it is simple or not. What is simple, is you can always lose detail in the client. The client can 3 prices as low / medium / high response and walk away. Oh, you have seven layers of DR response? Fine, set 7 prices in the client as very low / low / low-medium / medium / high medium / high / very high and walk away.

We are moving from a very light interface with no knowledge of the client to needing to know more about the client. We are moving from securable messaging that flows well over any combination of transports to HTTP[s] only.




"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


-----Original Message-----
From: Old, Bob [mailto:bob.old@siemens.com] 
Sent: Friday, December 04, 2009 6:13 PM
To: Dave Watson; michel@universal-devices.com; energyinterop@lists.oasis-open.org
Subject: RE: RE: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914 SK edits.doc) uploaded

Let me say at the start that I'm always one to let a 1000 flowers bloom.
So if we need EI to support some simple clients, let's put that in.

But as much as research is a vital part of a Smart Grid development
effort, research projects are not our goal.  We're looking at 10's of
millions of devices throughout North America for thousands of utility
companies.  We can't be making up custom code for every DR program.
That's why the only DR protocol BAS's support now is <10 Hz dry contact
closures from the Interval Meter.  

I don't believe any BAS vendors sell product features that take only an
hour of software development--much as I hate to admit we have a bloated
Engineering Development Process where it takes more than an hour to pull
down all the project document templates.

Other than Process, I expect any SG product development will spend a big
chunk of time in conformance/interoperability testing.  Another big
chunk will be taken up by meeting the security requirements of the Smart
Grid.  I've seen it up close, and the US Utilities are excessively
conservative (EU Utilities less so) with respect to security.  The CSCTG
<
http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/CyberSecurit
yCTG > headed by Annabel Lee of NIST has kept a low profile, but it's a
crosscutting issue that affects every aspect of the SG.  I expect this
site < http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml >
on Elliptic Curve Cryptography is another place to start slogging
through.  We'll all be sitting down with the Munitions Export lawyers
for some cozy chats about what to do so we can sell this stuff outside
the US.  

Best,
B.O.  December 4, 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

-----Original Message-----
From: Dave Watson [mailto:dwatson@lbl.gov] 
Sent: Friday, December 04, 2009 2:38 PM
To: michel@universal-devices.com; energyinterop@lists.oasis-open.org
Subject: RE: RE: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded

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

[Old, Bob] <snip>


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