[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 61850 Randomize and the Grid
This letters summarizes discussions in a variety of forums on how WS-Calendar 1.0 deals with the need to “Randomize” . Some of these conversations occurred in or around the OASIS Energy Interoperation TC. Some of the conversations occurred in the SGIB Smart Grid Architectural Council. They should be specifically validated or in-validated by this TC. This email is the promised summary on the Semantics of blurring signals and responses to signals. Clearly the power grid is hurt if every air conditioner in every house turns on at 6:15 sharp when the price goes down. Everything turning off at once also causes problems. When broadcast communications are to hundreds of 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 particle accelerators that negotiate each start and stop with the local utility. One in Florida schedules DR events in the local town around the 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 communication protocol 61850 includes a particular command “randomize”. A single randomize command to a substitution with a duration of 10 minutes tells all devices to start randomly during a 10 minute period. The intent is to blur the response, to avoid spikes, to present a simpler load curve to the grid. In WS-Calendar, this is specified with more options. The essential unit of scheduling is the Interval. And Interval may have up to five parameters that can be used to communicate blurring. Each interval can have a startBeforeTolerance, a startAfterTolerance, an endBeforeTolerance, an endAfterTolerance, and another parameter that specifies how precisely the response duration must match the request. The cross-cutting communications of the smart grid necessarily do not match all communications in niche locations precisely. How systems on the other side of an interface respond is always defined by conformance. 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, a pre-existing specification, 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. 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 its production lines. WS-Calendar is able to convey the information needed to request the blurring of the response curve, which is the purpose of the Randomize element. Because WS-Calendar is service rather than process oriented, it can use the same message to request a different domain to blur through a sequence or by a ramp. WS-Calendar is able precisely to define the blurring, including whether it occurs at the beginning or end of the response interval, as well as inside or outside the response interval. Randomize would muddy the semantics from the clear expectations communicated by WS-Calendar. Consider a 1 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? This is my understanding why the TC considered and rejected adding an explicit Randomize parameter. It reduced precision of communication, reduced the applicability of message, and did not add functionality. tc “The single biggest problem in communication is the illusion that it has taken place.”
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]