This last week, my attention has been swallowed by a tempest in the smart grid teapot. One application has solved a particular problem on one way. The problem is an important one, and they have done good work. The solution they want to impose on others will either reduce interoperation and scalability in other smart grid efforts, or overly constrain new technology.

The story is an interesting one, and applies to integration in buildings and building systems as well-so I thought Automated Buildings readers would like a ring-side seat at a story on smoothing energy response.

Clearly, the grid is hurt if every air conditioner in every house turns on at 6:15 pm sharp when the price goes down. Everything turning off at once also causes problems. When broadcast communications are targeted to millions of nodes, it is important to signal that a range of response-time are expected. Note that this is only a problem in broadcast scenarios.

A similar problem arises when communicating to single large loads. A single smelting facility may be able to jolt the grid as hard as a thousand homes. There are research facilities that negotiate each start and stop with the local utility. One particle accelerator in Florida schedules DR events in the local town around their research projects. For large loads, it is important to ramp.

When point to point communications are available, a central dispatch facility can manage these issues directly starting one, and then another.

The substation automation standard, IEC 61850, includes the semantic element “Randomize”. A current draft of 61850 adds an optional “Randomize” element to any message payload. A single randomize command to a substation with a duration of 10 minutes tells all devices to start randomly during a 10 minute period. The intent is to smooth the response, to avoid spikes, to present a simpler load curve to the grid. This is a good application-based definition of smoothing.

In WS-Calendar, similar intent can be communicated more nuance. In WS-Calendar, the essential unit of scheduling is the Interval. The Interval may have up to five parameters that can be used to smooth the transition effects at the beginning and end of an interval. Each interval may have a startBeforeTolerance, a startAfterTolerance, an endBeforeTolerance, an endAfterTolerance, and another parameter concerning interval precision that I will not discuss here.

The smart grid is an approach of communicating within a system of systems. The cross-cutting communications of the smart grid necessarily do not match all communications in niche systems precisely. How systems on the other side of an interface respond is always defined by conformance rather than semantics. The service model is to communicate intent, and to let the application respond.

An interface translating between information communicated with WS-Calendar and by 61850, needs a simple transform or translation. This translation can communicate any or all of the Tolerance parameters of WS-Calendar into a “randomize” signal within the 61850 protocol. Similar rules could translate the other direction.

[an error occurred while processing this directive]In other environments, the tolerances can be translated into a request for a smooth ramp. Such a request makes far more sense when talking to an industrial site. There is no manufacturing site that would accept a request to randomize the start-up of its production lines.

WS-Calendar is able to convey the information needed to request the smoothing of the response curve. This fulfills the purpose of the Randomize element. Because WS-Calendar is service rather than process oriented, a message containing the same artifact can be sent to several domains, some that smooth response through a sequence, some by a ramp, as well as those that do this by randomizing.

Adding the additional element Randomize would muddy the semantics from the clear expectations communicated by WS-Calendar. Consider a one hour interval beginning at 2:00 PM and running to 3:00 PM. It has a startBeforeTolerance of 10 minutes and a startAfter Tolerance of five minutes, meaning a conformant service can start any time between 1:50 PM and 2:05 PM. If there is a further Randomize interval of 10 minutes, what exactly, is the range of acceptable start times? Is it before or within the tolerance periods? Can a valid response begin a 10 minute randomize period at 2:05? A good information model must avoid this sort of confusion.

WS-Calendar is able to communicate the need for smoothing, including whether it occurs at the beginning or end of the response interval, as well as inside or outside the response interval, without additional sematic element. Adding that element would reduce the re-usability of messages.

Smoothing does not arise solely in grid to building communications. Within an industrial facility, for example, it is not unusual to have dozens if not hundreds of DX units for HVAC. Today these may be operated independently. REGENergy, for example, has marketed a product that relies on this for years. REGENergy retrofit such facilities by building a wireless mesh that manages starts using a pattern similar to that of Randomize in the IEC 61850 white paper. Others look forward to buildings with many autonomous systems, receiving calendar schedules, and perhaps start tolerances.

The important thing, for service oriented standards, is that we keep this sort of application level login out of the service specification. Services specify results, not technologies, and not methods. As buildings learn to talk to the enterprise, we will do well to remember this.

Last month the specification WS-Calendar 1.0 was voted out of committee. Early adopters are already applying schedule communications based on this specification to building systems operation and to LEED-oriented building design.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]