OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Dealing with Assets


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:

  • A lightweight dynamic discovery protocol to locate web services that composes with other Web service specifications;
  • A binding of SOAP to UDP (User Datagram Protocol), including message patterns, addressing requirements, and security considerations; and
  • A profile of Web Services protocols consisting of a minimal set of implementation constraints to enable secure Web service messaging, discovery, description, and eventing on resource-constrained endpoints.

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.


Toby Considine
TC9, Inc

OASIS Technical Advisory Board
TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]