[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Dealing with Assets
The idea of making sure EI is aligned with
the PAP17 efforts is a good idea. There are multiple mentions of demand
response on the PAP17 twiki and it also seems to address additional aspects of
DER in regards to DR. The last action I see on the twiki (A13)
is that requirements were submitted to ASHRAE on Feb. 8th 2011. Does
anyone have access to the requirements and what the subsequent ASHRAE model
looks like? The twiki page indicates that the work is
built from the existing PAP10 and IEC CIM models. If the EI model is also CIM
based, it should make the alignment easier. In the meantime, I think the 9 steps that
we have outlined so far for the next CD should still be our highest priority. Bruce
Bartell Xtensible Solutions From: Toby Considine
[mailto:tobyconsidine@gmail.com] On Behalf Of
Toby Considine I propose that we deal with the problem of Assets by
incorporating references to the WS-DD suite of specifications. The purpose of
the Web Services Discovery and Web Services Devices Profile (WS-DD) Technical
Committee is to define:
OpenADR 1.0 terms each premise a resource, able to provide
services to the grid. If we had mature markets, each premise would be
responsible for absolute energy use. Many industrial sites operate in this mode
already. Absolute results, though, are considered beyond the abilities of
today’s commercial buildings, and more importantly for today’s
homes. If the family arrives home during a DR event and starts cooking, their
energy use will go up even as though their thermostat was automatically turned
down. To assess performance in today’s markets, market makers want to see
some of what’s behind the ESI. To support this need, Energy Interoperation needs to
support some level of not-quite-direct control of systems or devices inside a
Resource, or perhaps merely some level of monitoring. We call these exposed
systems and devices Assets. It is important to think of an Asset as a virtual
device, one them may represent a smart toaster, a water heater, or an entire
production line in a factory. What matters is that a contract allows it to be
exposed and its function “directly” monitored. Distributed Energy Resources (DER) are a particularly
interesting class of Assets. The home solar panel, or the roof-top wind
turbine, or the grid integrated thermal storage system might all be Assets. In
any case, Assets need only a constrained set of interactions (On, off, half
speed, set thermostat to 76, is it running now, charge up, discharge, how much
electricity is it generating now…). Limited metadata is expected as well,
largely to let Transmission operators deal with covarying Assets. 500 solar
panels on the south side of town are covarying Assets as the same clouds might
take them all out at the same time. Today’s Assets are covered by
Tariffs, and this is all closely regulated. In the future, Assets may be
offered to the market as tenders, contracted, and exposed. I propose that we use the Managed Discovery Interface
defined by the Web Services Discovery and Web Services Devices Profile (WS-DD).
WS-DD is already used in many networks to discover services such as printers
and faxes. WS-DD is supplemented by Device Profiles (DPWS) to ascertain the
capabilities of each device. For example, you may want to find only printers
that support color and two-sided printing. Discovery only works local, as the
internet is built to prevent printer searches consuming all bandwidth. The
Managed Discovery interface offers a secure way to ask a remote system to share
the results of local discovery. You can imagine that corporate headquarters
allows remote employees to print at only a few designated printers. We can use
the same approach to share Assets with grid operators. To do this, we need to define Standard metadata compliant
with the Device Profile, including a list of available services and their WSDL
description. This standard metadata would be extended to define profiles of
interest to energy interactions, while excluding detailed interactions that
would increase complexity while reducing interoperation. We discussed whether
devices would expose separate services beyond those needed for energy
interactions. Fortunately, ASHRAE SPC 201 has been hard at work for
months, working with NEMA to define what the energy interactions for premises
based systems are. For some systems, these are quite simple. A thermostat might
expose a method to turn it up for a period of time, and a method to verify its
current setting. For now, these services could be registered by hand though the
system that hold the ESI. In the future, such systems may be able to
autodiscover systems, and ask the [owner] which ones to share with the energy
market. Assets need some
concept of Events, that is, a way of notifying remote systems of things that
change locally. WS-DD prescribes the use of WS-Eventing. This specification
defines how to support supports the simplest levels of interfaces for
notification producers and consumers for a distributed event management system.
WS-Eventing is a W3C recommendation that is widely implemented in the
enterprise. We can use these
specifications to solve critical needs for Energy Interoperation without
delaying its final completion. This decision would also define the feedback
events for Asset interactions. The interactions described above are well known
and well understood. Moreover, this decision takes the precise form of the
Asset Profiles needed outside of the Energy Interoperation TC, allowing them to
be defined when ASHRAE completes its work, or by the OpenADR Alliance, or…
The Precise needs and forms of Profiles under DPWS are already well defined. “It
is difficult to get a man to understand something, when his salary depends upon
his not understanding it” -- Upton Sinclair.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]