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