[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [smartgrid-interest] Draft Charter - Energy Market InformationExchange (GEOSPATIAL)
|
I had to comment on the Geospatial portion of this. DR (Demand Response) is the means that the utilities use today
to get users to shed load (“Nega-Watts”) during times of peak load.
In some regions, they will pay handsomely for this shed. There is a critical
mid-market group known as the DR Aggregators. Depending on local policy and
politics, many of the utilities have a love/hate relationship with the DR Aggregators,
either seeing them as a middle-man to be gotten around, or a critical service
provider. DR Aggregators are often involved with building performance
optimization or business process re-engineering as appropriate. As might be expected in such a prickly relationship, the DR
Aggregators are not necessarily interested in revealing all of their customers
by name. On the other hand, as the T&D grid is definitely a flowing network
with bottle necks, it may be necessary to report on exactly which portion of
the grid the reduced load is going to be achieved. If the end nodes (homes, businesses, industry) know their point locations,
using OGC specs (KML?), to report location of NG-911, then the value/cost ratio
improves, getting a two-fer on the initial set up. If the [distribution] grid
is described as an OGC specified polygon, then it becomes straightforward for
the aggregator to sum DR promises by geographic polygon / rete of the grid. If
the bottle-neck is further upstream, it becomes straightforward to sum across
polygons. If two competing DR Aggregators are working the same territory, it
becomes simple to sum those reports for the same polygon, and price appropriately. And if they fail, and that substation fails, and that same
polygon is down, then that is another report back to the first responders
indicating intersections where traffic cops needs to direct traffic, and
neighborhoods that may require increased patrols… 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: William Cox
[mailto:wtcox@CoxSoftwareArchitects.com] Lance - William Cox
Bill, A few suggestions for the draft charter for the
proposed OASIS Energy Market Information Exchange (eMIX) Technical Committee: 1) The draft charter states, "European markets
have an additional area of interface, between Transmission and Distribution (in
American terminology), as these are typically under separate ownership. As time
allows, or in a future update, the TC may address those needs as well."
I think it's important for your "Enterprise View" to include
these needs without fail, because -- Customer ownership of microgrids (a la Galvin Institute's
"Perfect Power") will be likely be a critical factor in the
transition from centralized to distributed generation, globally. Distributed
generation is very much driven by new opportunities for distributed ownership
and control of energy assets. -- Global product deployment and customer acceptance of the
new standards will require international participation, or at least
consideration of other nations' requirements, in the development of the
standards. Larger markets encourage investment, innovation, technology convergence
and lower prices, so everyone will benefit if the standards are global. Rapid
national and global market rollout of distributed generation has important
national and global security benefits and economic benefits. 2) The Enterprise view for Smart Grid commerce
standards needs to explicitly state that ownership of each physical
"feature" (meter device, device metered, building, right of way,
etc.) matters. 3) The Enterprise View for Energy Market
Information Exchange should explicitly state the need for standards to
support measurement, control and real-time buying/selling (and sometimes
regulating) not only of electricity but also of fuels and combustion (and
emissions, such as wood smoke in urban settings), water and sewage and perhaps even
bandwidth usage. Also, end user and small generator participation in carbon
trading needs to be explicitly enabled and not inadvertently precluded by the
standards. Detailed standards for the electric power markets should come first,
but as part of a comprehensive and coherent high level "smart pipes and
wires" standards framework. 4) I missed the end of the comment period for the draft
charter of the OASIS Energy Interoperation TechnicalCommittee, so I failed to register
my comment (offered as an OGC consultant) that indoor and outdoor spatial
locations and spatial relationships matter. But this is important for commerce
as well. Geospatial standards from the Open Geospatial Consortium (OGC), ISO
TC/211 and IEEE 1451 are in wide use and need to be incorporated into the Smart
Grid standards ecosystem. OGC and the buildingSMART Alliance recently completed
the first in a planned series of multi-sponsor, multi-participant
AEC-Owner-Operator (AECOO) Testbeds in which energy is an important focus.
Follow-on AECOO Testbeds will likely involve the OGC Sensor Web Enablement and
IEEE 1451 "smart transducer" standards. OASIS has a memorundum of
understanding with the OGC. The OGC's CTO is Carl Reed (creed@opengeospatial.org). The
buildingSMART alliance contact for the AECOO testbed is Christopher Groome (chris.groome@b-r-t.co.uk). The IEEE
Instrumentation and Measurement Society’s Sensor Technology Technical
Committee is chaired by Kang Lee (kang.lee@nist.gov). Thank you for the opportunity to offer these comments. Lance On Mar 30, 2009, at 10:43 PM, William Cox wrote:
I've attached a draft charter for the proposed OASIS Energy
Market Information Exchange (eMIX) Technical Committee. -- <Energy Market Information Exchange TC Charter
20090330.pdf> --------------------------------------------------------------------- To unsubscribe, e-mail: smartgrid-interest-unsubscribe@lists.oasis-open.org For additional commands, e-mail: smartgrid-interest-help@lists.oasis-open.org |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]