[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix] I need some feedback - oBIX next steps and the smart grid
We see things alike. OASIS Energy Interoperability TC [energyinterop] , formed a
month ago, includes OpenADR and Price/product signals to the [end node] OASIS Market Information Exchange TC [emix], call for participation
any day now, models as you describe. FWIW, emix is about prices, not tariffs.
Tariffs may be thousands of pages of legalese, but it results in prices that
are much simpler. Something I am calling WS-Calendar, which may come out of the
IETF. WS-Calendar can then be in EMIX, ENERGYINTEROP, oBIX, BPEL, WSDM, etc as
a component I have long felt it will be easier to get acceptance of WS-Calendar
if it come from above rather than from w/I a building control protocol. 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
From: Brian Frank
[mailto:brian.tridium@gmail.com] That makes sense. Here are some thoughts... I don't know of any gotchas using oBIX historian, but if
oBIX was used and anything comes up, I think we could solve it pretty quickly. The second issue a bit more involved. To effectively
do that probably requires modeling: - rate structures - financial models - schedules and time ranges From being involved in previous energy applications, I would
suspect modeling the rate structures would be the most complicated aspect and
would tend to drive the scheduling aspects. It is hard for me understand
how stand alone scheduling would integrate into that (maybe with some sort of
iCAL RRULE). However it works, I think the key issue is that new models
must be defined (or existing models formalized). And one thing oBIX
excels at is specifying models :-) Brian On Mon, Jul 27, 2009 at 5:47 PM, Considine, Toby (Campus
Services IT) <Toby.Considine@unc.edu>
wrote: 1) I will propose that the oBIX historian
function is just fine for all the meter information we need. I was asking if
anyone knew of any gotchas that I did not. 2) Many of the problems of the smart grid
are precisely those of synchronizing performance. Energy will be very scarce
from 2:00 to 3:45 tomorrow (based on weather reports) = = > Energy will be
very expensive tomorrow from 2:00 to 3:45 tomorrow = = > What would I need
to be paid (as an enterprise) to degrade the business services I am offering
tomorrow from 2:00 to 3:45 tomorrow = = > 3rd floor, go to
operating posture 3 from 2:00 to 3:45 tomorrow. The problem with the iCAL
implementation is there are so many of them. Ideally, we would have a common
iCalender/XML for the event, for the price, for the enterprise, and for
oBIX… (see the Daboo serialization, now floating through the IETF) "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: Brian Frank [mailto:brian.tridium@gmail.com] Toby, If the basic problem is how to represent and query real-time and historical
data - is not oBIX as is sufficient? In what regards is scheduling a requirement for Smart-Grid? Is there
some specific use cases? Aaron has posted a draft for how it will work in
oBIX based on iCAL. It is really just a question of getting
implementations and going through the standards process. Brian On Sun, Jul 26, 2009 at 10:16 AM, Considine, Toby (Campus Services IT) <Toby.Considine@unc.edu>
wrote: As many of you know, I have been working on the roadmap for smart grid
standards this year, a task that has consumed my time and made me a poor
convener of meetings. The smart grid is one huge mass of legacy systems and legacy protocols. The
most interesting part of the smart grid, too me, is its interactions with the
end nodes, i.e., industrial sites, commercial buildings, and homes. The grid,
by its very nature, must be conservative and slow to adopt new technologies.
The end nodes can be more agile, and can support more diverse technologies. A
key aspect of the smart grid is creating informational (and economic)
interfaces that enable the end nodes to solve the grids most critical problems
of dealing with increasing unreliability (we are by policy introducing
unreliable energy sources) and balancing supply and demand. On the building side, architectural sketches are looking to two interfaces,
the meter and the energy services interface (ESI).
The ESI is the locus for a variety of services, including Demand Response, that
I will not go into here. The Meter is a special interface, a secure SCADA
end-point for the grid, the secure cash register for energy purchases, and an
information source (read only) to the end node. One of the high priority (and highly visible) (and
politically sensitive) items in the US smart grid road map is access to live
metering data. This problem presents in several forms. How do I get interval
data from the Customer Information System (CIS) of the utility? How should we
standardize read-only access to the newly designed smart meter? How do we
standardize data read off legacy meters to a format that can be consumed by a
variety of software tools inside the premises? How do we present interval data
(by relay or proxy) up to a 3rd party energy manager or presentation
tool such as Google Energy? To me, this a natural use for the historian
functions (section 14) of oBIX. This is precisely the type of scenario for
which oBIX was developed: a common abstraction of functions common to all
control protocols, readily understandable without domain knowledge, and
abstract enough for enterprise interaction. I have long wanted oBIX 1.1 to use WS-Calendar functions for scheduling,
rather than developing its own. This has made me dilatory on scheduling
meetings, as WS-Calendar is in a perpetual “real soon now”™
state. I have recently shared the links to the IETF drafts on schedules with
this committee. Source: http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-00
Source: http://tools.ietf.org/html/draft-daboo-calendar-availability-01
Source: http://www.newdaedalus.com/articles/2009/6/6/schedules-for-things-and-markets.html The question is, should we finish 1.1 without waiting for Calendar,
eliminating the known ambiguities, and standardizing the RSS/ATOM subscription
functions? Please respond to the list or to me. I will be on the road most of
this week, and the first half of next week. The next week begins with a
conference that some of you will be at on developing plans to resolve the
priority actions (including meter information sharing) for the next two years
of the roadmap. If someone wants to talk, 919-619-2014 If someone wants an evening meeting (east coast) next week I can make it.. tc "It is the theory that decides what
can be observed." - Albert Einstein
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]