[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: I need some feedback - oBIX next steps and the smart grid
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]