[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [smartgrid-discuss] Draft charter for proposed OASIS Energy Interoperation Technical Committee
When defining the requirements for how the
various interactions between energy providers and their customers are
transacted, we will find that they will be specified at various levels of
abstraction. One level of requirements that the UCAIug will be able to define
(no doubt expressed as a collection of use cases) is to specify WHAT interactions
are required for the Utility/ISO’s currently envisioned processes.
Another level of requirements that I believe OASIS will play a major role in
defining is the MANNER in which those interactions are transacted. The
requirements of symmetry, composition, and transparency that Toby enumerates
are examples of this. As an aside I think these are very good
requirements and I agree with them. The responsibility of OASIS should be to
insure that not only can the currently envisioned set of use cases be fulfilled,
but that some of the future uses cases that were not envisioned be made
possible by imposing further requirements on the manner in which the
transactions are conducted. Almost by definition these types of requirements
are not easily expressed as use cases since if they could then they would have
been envisioned. The duality of the WHAT type of interactions
that UCAIug can bring to the table coupled with the MANNER of transactions that
OASIS can add is why I am so bullish on the collaboration between UCAIug and
OASIS. I don’t want to imply that OASIS
will not contribute to defining WHAT interactions are supported. In fact I
think that OASIS can play a major role in helping to represent the non-Utility/ISO
side of the equation, but if there is not buy in from the Utility/ISO’s those
requirements will likely become irrelevant. Furthermore as anyone that
has done business with Utility/ISO’s can tell you, transformative change
is problematic. -ed koch From: Considine, Toby
(Campus Services IT) [mailto:Toby.Considine@unc.edu] The wonderful thing
about [smartgrid] standards is that there are so many of them… I think
Glenn’s comments are well important in this effort. The most important
and rarest addressed are the issues surrounding what Glenn calls the problem of
bi-directional power and the problems of rapidly increasing diversity in the
grid, diversity of technology, of owner, or connection… These requirement to
solve these issues are why we have a focus on symmetry, transparency, and composition. Symmetry assumes
that each action can be run both ways. Symmetry might refer to buying or
selling of power. Symmetry might refer to the end node making inquiries about
capacity and reliability up the energy delivery chain just as the grid operator
might make the inquiry down. Symmetry suggests that end nodes have as much
capability to make inquiries up about fulfillment, whether it be of carbon
strategies or of reliability as the ISO has the right to make a fulfillment
request down following a DR event. Transparency is
critical as more payers enter every market. Transactional energy demands that
there be verifiable transactions about the sources and uses of energy so market
can clear. Want to buy a certain class of power as part of a carbon strategy?
There had better be an auditable chain of transactions showing that the
markets actually cleared in each class of power. Transparency of operations
also comes across as part of the issues in symmetry as above. Composition is a key
component of supporting diversity. Corporate Development of software in the
90’s was crippled by a misapplication of theories demanding universal
database models be in place, agreed to by all, before work could proceed. How
is this different then the focus on the CIM that is still embraced in power.
Composition offers a simpler way to assemble functionality, focusing on the key
requirements for each aspect and no more. Th4e killer apps of the internet,
used by billions of people to interoperate with using diverse software, work
because they are composed of simpler protocols, and when one party does not
understand one of them, communication and functionality is diminished but not
destroyed. Transactional
markets for energy in a building? Perhaps no security. Transactional markets
for energy in the neighborhood distribution loop? Perhaps simple token or
address based security. Transactional markets for energy on the big grid? Full
blown federated identity management with mutual authentication is required.
Does the CIM even need to know? No. Similarly,
interactions between symmetrical nodes can be composed of smaller standards,
each less specific than is a full blown data model, each applicable in more
areas, and each optional for the node in question. Small standards for metering
power use can be separate from the bidding and negotiations to come up with the
power prices. The bidding and negotiations, including DR, for, say, electricity
and natural gas can be the same. Status and capability information can be
exchanged irrespective of the flows, and used to manage system capabilities.
Status and capability do not demand the purchaser (this moment) know the
technology used to generate the power. This information can be composed with
other standards including the more intimate ones required of the energy asset
in a end node is managed as a forward asset of the supplier So let’s look
at the other standards, and learn from them. But my first question for
each is does it support symmetry, transparency, and composition… "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
From: Glenn Skutt
[mailto:gskutt@vpt-es.com] Bill, On Tue, Feb 10, 2009 at 11:51 PM, William Cox <wtcox@coxsoftwarearchitects.com>
wrote: Please find attached the draft charter for the proposed OASIS Energy
Interoperation Technical Committee. I've attached a PDF, OpenDocument, and Word
versions, all with line numbers for ease of discussion and review. --
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]