!!!! I apologize for
the length of this email but we are cutting to the core with this very
important discussion. !!!!!
OpenADR represents a
specification with a functional prototype that implements a set of real-world
requirements through the integration of several very important use case
scenarios including DR eventing and pricing. These do not represent all
of the envisioned SmartGrid interactions but they do represent the highest
priority ones based upon the repeated message that we should not "boil the
ocean" and solve the need for a DR standard. Our great ideas concerning a free
market for energy are tempered by the reality that we start with a very rigid
and diverse regulatory environment and that the electrical infrastructure is
critical. (I think that everyone would agree that a market meltdown would be
unacceptable!) Resolving all of the regulatory issues will take time and time
we do not have. I see two "givens"; 1) real DR projects are moving forward
with or without standards and 2) the SmartGrid will evolve over time. The
classic approach of fully-defining the requirements upfront using a rigorous
water-fall methodology is not appropriate for the SmartGrid, just like it
wasn't appropriate for the Internet. We need to adopt an iterative and
evolutionary methodology. (The attached article by Denning discusses in more
detail.)
So what is the best
path forward? How can we make the most progress in the least amount of time
while not compromising a future that we don't fully understand? We take what
we do understand and create a core set of information models that represent
key information content that needs to be communicated. This focuses on
what needs to be communicated
and not on how it is
communicated. We are under a mandate from Congress to be "flexible to
incorporate regional and organizational differences and technological
innovations". These standard information models are then incorporated within
specific service and transport standards which can be baked into products. By
separating the information models from the specifics of a technical
communication standard, we permit the two to evolve and grow over time while
minimizing the "impedance mismatch" between protocols. There is no doubt that
the same information will need to flow through different communication
channels using different transaction models, security models, etc. These are
very application and context sensitive and include emerging technologies such
as Cloud computing. (I'll restrain from writing another
volume:-))
Ed has outlined below
a very reasonable approach which could form the basis for achieving the
definition of a core set of information
models upon which we can build: A hierarchy of information components with data
models and schemas. This hierarchy needs to be concise yet not too
complex and we need to be very mindful of minimizing unnecessary dependencies
which may seem elegant but only increase brittleness. The hierarchy must be
designed for evolution and change. At the center will be flexible
micro-specifications such as a pricing model with temporal scheduling. (This
could even evolve into an RDF mesh model over time…) Once these models are
defined, then we could focus on building a set of service interfaces and
transactions which would wrap and transport the schema-defined data
models.
The
challenge that I would like to propose to the NIST DEWGS, OASIS and DOE GWAC
is to set a target to define a core set of strawman information models, which
include a flexible DR event model and flexible pricing model, by Connectivity
Week in June! (Or earlier!!) How should we organize ourselves to achieve this?
We have the talent but are limited in resources and funding. Can we do this or
do we just sit on the bench?
One last thought: In
software, progress is made by "standing on the shoulders of
giants".
Happy
Holidays!!!!
Dave
Dave Hardin, PE, PMP,
CSDP, MCAD
Invensys Global
Development
33 Commercial
St.
(C42-2E)
(w) 508-549-3362 (c)
774-571-5386
From: Edward
Koch [mailto:ed@akuacom.com]
Sent: Wednesday, December 17, 2008 1:59
AM
To:
smartgrid-discuss@lists.oasis-open.org
Subject: [smartgrid-discuss] RE: Purpose
of the Discussion Group - was RE: Introduction: The Demand
Side
Took awhile for this
to bubble up to the top of my task queue, but here are some thoughts on Toby’s
questions below.
OpenADR is really a
cross cutting application and therefore I think that it could be a collection
of more vertical standards that when bundled (i.e. think composition) together
in a certain way constitute OpenADR. Furthermore I think there is
actually a hierarchy of how such things are bundled together. For
example at one level there should be a specification associated with the
various core interactions, i.e. things such as bidding might be one class of
interactions while delivery of DR signals might be another class. It is
important to note that not all DR programs will require a bidding interaction
so it is useful to make that a separate class of services that may or may not
be used within a particular DR program.
Furthermore within
each class there might further be a collection of standards (Toby’s
mico-specifications) for things like pricing and schedules. Some of
these will not be so much about “services” as they will be about agreed upon
data models and schemas that may be used within a
service.
Of course there is
also the cross cutting issues (security, reliability, non-repudiation, etc.)
that constitute the necessary evils of the plumbing that almost certainly
should be incorporated by reference to other
standards.
-ed
koch
From:
Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Thursday, December 11,
2008 3:46 PM
To:
smartgrid-discuss@lists.oasis-open.org
Subject: [smartgrid-discuss] Purpose of
the Discussion Group - was RE: Introduction: The Demand
Side
Within the OASIS
framework, discussion groups are short lived mechanisms from which one or more
Technical Committees (TCs) are formed. Of course, the answer might be zero
TCs.
A TC has a
discrete charter, and a discrete goal, and even a discrete IP policy. Subject
matter discussed within that TC is subject to that TC’s IP policy. This may
limit participation. For example, if the TC policy is that all IP is given
free and clear to implementers, then it may be that some corporations would
forbid some of their employees from participating in that TC. It is necessary
that there be some rules in a TC, and in TC
communications.
As we were not
ready to do that, we have this discussion group.
Here are some
questions that I have about direct focus and TC formation and OpenADR. These
are off the top of my head, so there is no ex cathedra
here…
-
Is
OpenADR one standard or several?
-
If
OpenADR is one standard, is anyone ready to write a
charter?
-
If
OpenADR is several standards what are they?
-
In
what ways can OpenADR achieve some of its goals by reference to other
standards. I’m thinking WSDM / BPEL / oBIX / WS-Security /
…
-
Is
it worthwhile to spin off some micro-specifications. I have mentioned
WS-Scheduling, to establish a common standard for DR / Building Operations /
Business Process and then merely refer to that specification from within
OpenADR?
-
Are
there other micro-specifications? What are they?
Moving beyond
OpenADR…
-
If
an OpenADR end point is a net zero building, what is the common service
framework?
-
Is
there some lightweight service oriented version of 61850 appropriate when no
exchange of operations information is needed (NZE) but when reliability,
capacity, and safety information must be exchanged? (Note to e-commerce guys.
IEC 68150 is the substation operations standard. If you put power on the grid,
you are a substation).
-
Is
there a common transaction model for power moved / time of day that can be a
fully symmetric service? (Borrowed from AMI, I assume) (e-commerce guys – AMI
is Automated Metering Infrastructure)
And then we have
the security issues, or perhaps meta-issues:
-
How
do we apply federated identity management across these energy-related
services?
-
Are
there standards for delegation, including delegation of market operations
(DR), delegation of gear operations (now we are back at 68150) et al.
-
What other
delegations are needed?
Finally, I see
some bigger issues that *I* am
not ready to wrestle with yet. I see these as waiting until after the
Grid-Econ summit in March
-
How
do we transmit forward prices over time intervals in bidding
situations?
-
How
do we transmit forward energy profiles over time intervals in bidding
situations?
-
Can
promised energy profiles be enforceable? (throttling use at the meter per
agreement)
-
How
do we carry out a forward agreement?
I think these
are all service-related issues (services as in SOA) tied to e-commerce
surrounding the grid. Some of these we will define enough to launch TCs
around.
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 |
From: Edward
Koch [mailto:ed@akuacom.com]
Sent: Thursday, December 11, 2008 6:18
PM
To:
smartgrid-discuss@lists.oasis-open.org
Subject: RE: [smartgrid-discuss]
Introduction: The Demand Side
Being the OpenADR guy
I would be more than happy to focus on that topic, but if that was the
intention of this particular mailing list then I may be confused as
well. From my recollection there was a decision within the NIST B2G DEWG
to start an OASIS discussion group to talk about smart grid stuff in general
and I thought that is why this group was formed. Coincidentally the very
next day there was a tentative decision within a different forum to start an
OASIS group for OpenADR. Obviously OpenADR is subset of smart grid
and what we are doing with the NIST DEWG's and thus it is fair game to talk
about it within this mailing list, but I too then have the same question
as to the focus of this group.
-ed
koch
From: John
Gillerman [mailto:johng@sisconet.com]
Sent: Thursday, December 11, 2008 2:55
PM
To: 'David RR Webber
(XML)'
Cc: 'Considine,Toby
(Campus Services IT)'; smartgrid-discuss@lists.oasis-open.org
Subject: RE: [smartgrid-discuss]
Introduction: The Demand Side
I think it would be
good to make progress on narrowing down our scope. Not that this
should dictate things, but I joined this group with the understanding that
this group was formed to review and refine the OpenADR
proposal. What would you say is the target of our efforts is?
From: David
RR Webber (XML) [mailto:david@drrw.info]
Sent: Thursday, December 11, 2008 5:47
PM
To: johng@sisconet.com
Cc: 'Considine,Toby (Campus Services
IT)'; smartgrid-discuss@lists.oasis-open.org
Subject: RE: [smartgrid-discuss]
Introduction: The Demand Side
From the OASIS
perspective - that's the purpose of a discussion group - to assess
interest - work towards a proposal proposal for standing up a
TC.
--------
Original Message --------
Subject: RE: [smartgrid-discuss]
Introduction: The Demand Side
From: John Gillerman <johng@sisconet.com>
Date: Thu, December
11, 2008 2:28 pm
To: "'Considine, Toby (Campus Services IT)'"
<Toby.Considine@unc.edu>,
smartgrid-discuss@lists.oasis-open.org
Toby,
Thank you for the
clarification. I guess I am struggling to figure out what exactly is
the scope of work in this group. Do we have a picture that shows the
systems/actors involved and how we expect the output of this group to be
used? Was a mission statement created for this
group?
John
From: Considine,
Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Thursday,
December 11, 2008 1:27 PM
To:
smartgrid-discuss@lists.oasis-open.org
Subject: RE: [smartgrid-discuss]
Introduction: The Demand Side
I know
OPC, I have debugged OPC incompatibilities deep into the night. I also
respect the new Unified Architecture, and the efforts to modernize OPC
to take into account web services. If you like, we could even get into
whether OPC has damaged itself by over-respecting legacy and including
serialized COM in UA. I also know MIMOSA and respect its roadmap.
OPC will
continue to have a strong position in industrial sites, including many
used in power generation. Many industrial assets that respond to DR will
marshal that response using OPC. There may be strong reasons why
internal sub-station operations may be performed in
OPC.
But OPC is
probably not the tool for inter-organization communications crossing
bounds of identity and authority in economic
interfaces.
On another
note, the BACnet Load Control objects are a very interesting overlay to
the BACnet protocol. Many commercial spaces will use these objects to
marshal response to a DR request. The abstraction the Load Control
objects offers and it pre-adaption for web services might make it a
superior solution for outsourced energy management by new market
aggregators.
But BACnet
is also not the tool for inter-organization communications crossing
bounds of identity and authority in economic
interfaces.
Many
substations are still run on MODBUS. oBIX is a great way to overlay
MODBUS operations with a standard web service to process information, or
to abstract between different control systems including OPC, MODBUS, and
BACnet. But oBIX is also not the tool for inter-organization
communications crossing bounds of identity and authority in economic
interfaces.
To the
grid, these are all internal protocols of the nodes, not the intermodal
communications. Some nodes are a simple as a light switch. Other nodes
are as complex as multiple coal and nuclear plants on a single site. OPC
would be great for the latter.
But I
think we are looking for the service interface to systems using those
protocol and architectures, as well as to others.
No
disrespect was meant…again “Consider
this an educational cartoon…”
"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
Chair, OASIS
oBIX TC
Facilities Technology Office
University of
North
Carolina
Chapel Hill, NC |
|
blog:
www.NewDaedalus.com |
From: John
Gillerman [mailto:johng@sisconet.com]
Sent: Thursday,
December 11, 2008 1:05 PM
To: Considine, Toby (Campus
Services IT); smartgrid-discuss@lists.oasis-open.org
Subject: RE: [smartgrid-discuss]
Introduction: The Demand Side
I wouldn't call
OPC a "low level
control system protocol". For more
information you may want to visit the OPC Foundation web
site: www.opcfoundation.org
From: Considine,
Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Thursday,
December 11, 2008 12:57 PM
To:
smartgrid-discuss@lists.oasis-open.org
Subject: [smartgrid-discuss]
Introduction: The Demand Side
I am
continuing to frame the subject some for those new to power here with
a few stage-setters, here and on my
blog.
Again,
apologies to some who will feel I missed some nuances, as I know I
have. My goal is to help some get up to speed quickly… Consider this
an educational cartoon…
Smartgrid
Basics: The Demand Side Problem
Building
systems have traditionally been invisible and uncontrollable. They
have been managed to reduce costs with no real focus on the service
they are providing. They have grown up in sandboxes, using their own
peculiar protocols. These protocols are deep and technology specific,
and often without effective interface. These systems are operated,
when they are operated by process
specialists.
Building
occupants rarely have a precise understanding of how these systems
affect their business. They may know exactly what a too-hot or
too-cold call costs. They know that tenant dissatisfaction may lead to
un-renewed leases. They may suspect that under ventilation may lead to
sleepy occupants, but can rarely put any exact price tag on that. This
makes them conservative about making changes in building operations.
Demand
Response (DR) is emerging a critical tool for dealing with peak load
management. Peak loads are by far the most expensive and dirtiest
electricity we have; their costs, on both bottom lines, swamping
others. Demand response is moving from direct control to economic
incentives, but underneath, today’s integrations are process centric
rather than service oriented. Energy providers order or pay energy
customers to turn off things on just a few days a year, to manage the
peak. We encourage only the crudest, least effective energy savings,
while denying the market the energy signals that would cause better.
At the
commodity system level, DR is already moving to services and agents.
Agents defend their own mission while responding to the outside world.
Washing machines know not to respond to grid signals until they
determine that the current laundry is not soaking in bleach.
Refrigerators know not to respond if they have just finished a defrost
cycle. These systems know and understand what services they provide
and so are ready to be responsive. Building systems are
not.
We will
get larger DR when we talk to the building occupant. We will get
better participation when the occupant remains in control. The
occupant will not allow DR when the in-laws are coming for the
weekend. The occupant knows the family overspent at Christmas and is
willing to respond to any and all incentives. The access control
system may know that only three people on the fourth floor came to
work today. Human resources knows that the sales force is on a
retreat. Together, they can choreograph far greater response from the
building systems then ever will be permitted as an automatic response
from control communications.
Demand
Response must be about economic signals to a business entity. When
thought of in this way, there is no need for different signals to
Industry and to Business (and to home and to vehicle). The business
may choose to automate this. The business may benefit from templates
for response, whether developed by EPRI or by ASHRAE, which reduce the
risk of considering participation. These choices and these templates
are not part of the interface.
The
interface should not does not concern itself with the underlying
technology and control protocols. It should not be based upon BACnet,
or OPC, or LON any number of other low level control system protocols.
The interface must be one that enables business decisions. Control
systems should offer up service interfaces for choreographed response.
Whatever offer and counter offer DR requires, whether amount of load
shed or maximum load used or time to respond must be in the interface,
but no deep process.
The
smartgrid to building/industry/home interface is about how the
Service
Oriented Building can respond to the
Service Oriented Grid. Just as in other services, the underlying
processes should be hidden.
"It is the
theory that decides what can be observed." - Albert
Einstein
Chair, OASIS oBIX Technical
Committee
Co-Chair, OASIS Technical Advisory
Board
Facilities Technology Office
University of
North
Carolina
Chapel Hill, NC |
|
blog:
www.NewDaedalus.com |