10.2 Common application functionality
10.2.1 Overview
This subclause describes common application functionality guidelines for features like randomization and active URIs that apply to more than one function set or in circumstances like adjacent or superseding events where special cases arise or need clear guidance to result in predictable behavior.
10.2.2 Active List elements
The Active List elements of a function set allow client devices to easily find the active instance of a specific resource. This makes it easier for constrained devices to find the information they are looking for without the need to explore a large list. Many of the function sets will provide this resource, including Demand Response, Messaging, and Pricing.
Active lists contain a subset of the instances in the full list of events for a given resource.
10.2.3 Event rules and guidelines
10.2.3.1 Introduction
These rules and guidelines are meant to specify client behavior in situations in which adjacent, nested, or overlapping events could cause clients to behave in an unexpected or undesirable manner.
10.2.3.2 Definitions
The following definitions define terms that will be used throughout the event rules and guidelines subclause. These terms, when used, are italicized for emphasis.
Event: Refers to any instance of a resource with a defined valid duration for which a client should take action. This would include all resources that are derived from the Event resource defined in the schema (IEEE Std 2030.5 supplemental material).
Start Time: Contained within the interval attribute of an Event resource representation and indicates when the Event should start.
Duration: Contained within the interval attribute of an Event resource representation and indicates for how long the Event is active.
Specified End Time: Time when an Event completes as specified in the instance’s interval attribute. This is calculated by adding Duration to Start Time.
Scheduled Period: Represents the time between the Start Time and the Specified End Time of the Event. A Scheduled Period is a Duration anchored at a specific Start Time.
Effective Start Time: Represents the time at which an Event’s interval attribute indicates commencement based on the Start Time plus or minus any applied Start Randomization offsets as calculated by the Client.
Earliest Effective Start Time: Represents the earliest time at which an Event’s interval attribute could indicate commencement. Calculated as the minimum of Start Time or Start Time plus the Start Randomization specified by the event.
Effective End Time: Represents the time at which an Event’s interval attribute indicates completion based on the Effective Start Time, plus Duration, plus any applied Duration Randomization offsets (which may be a positive or negative value) as calculated by the Client.
Effective Scheduled Period: Represents the time between the Effective Start Time and the Effective End Time.
Duration Randomization: The bound on the amount of time to be used when randomizing the completion of an Event.
Effective Duration: Represents Duration with Duration Randomization applied.
Overlapping Event: Defined as an Event where the Scheduled Period covers part or all of an existing, previously scheduled Event from the same function set, regardless of the controls present in the Event.
Start Randomization: The bound on the amount of time to be used when randomizing the commencement of an Event.
Successive Events: When the Start Time plus Duration of the first event is the same as the Start Time of the second event without randomization.
Nested Events: Defined as two Events where the scheduled Start Time and Specified End Time of the second Event falls during the Scheduled Period of the first Scheduled Event and the second Event is of shorter Duration than the first Event. This is an extreme case of Overlapping Event.
Override: A local act by the end user (e.g., a button press).
10.2.3.3 Rules and guidelines
In the text below, some rules and guidelines will be identified as specific to “function sets with direct control.” These function sets exert direct control over clients’ behavior and are typically used to manage service provider infrastructure through incentive programs to the HAN owner. This is in contrast with informational function sets that provide data to clients for display and awareness purposes such as Billing, Messaging, and Pricing. Function sets with direct control primarily include DRLC and DER. Pricing is somewhat unique in that it exerts control-like effects upon price-responsive clients; however, it is not a
form of direct control from the service provider’s point of view. The following rules and guidelines apply to both types of function sets unless specifically noted.
The depicted behaviors and required application management decisions are driven from the following guidance and rule set:
a) Clients that act on events that do not subscribe to their Event lists SHALL poll the lists for new
Events at least once every 15 minutes and SHOULD poll at least every 5 minutes.
b) Clients SHALL monitor the active Event(s) for status changes at least once every 15 minutes and SHOULD monitor at least once every 5 minutes. Note that these resources might be acquired in meeting requirement a) above; additional polling might not be needed.
c) Editing Events SHALL NOT be allowed except for updating status. Service providers SHALL cancel Events that they wish clients to not act upon and/or provide new superseding Events.
d) For function sets with direct control, Flow Reservation Responses with the same subject mRID, and the Pricing function set, clients SHALL NOT simultaneously execute or report execution of multiple simultaneous Events (e.g., Nested Events and Overlapping Events). The rules below clarify the expected behavior in cases in which either of these situations arises.
e) A client SHALL consider the current Event complete if a superseding Event is started.
f) When comparing two Nested Events or Overlapping Events from servers with the same primacy, the creationTime element SHALL be used to determine which Event is newer and therefore supersedes the older. The Event with the larger (e.g., more recent) creationTime is the newer Event.
g) Events presented to the HAN SHOULD make minimum use of Overlapping Events and Nested Events. Overlapping Events and Nested Events SHOULD only be used where changing conditions mandate superseding previous Events.
h) When changing conditions mandate changes in the sequence or contents of Events, the following guidelines MAY be used to indicate desired actions:
1) Canceling existing Events and reissuing new Events.
2) Sending overlapping or nested Events to supersede existing Events.
i) When a Nested Event completes, the containing/superseded Event SHALL NOT be reinstated and SHALL remain in a superseded state.
j) For function sets with direct control, it is RECOMMENDED that process h)2) be used for most situations since it can allow a smoother change between two sets of directives but in no way does it negate the responsibilities identified in rule g).
k) Clients SHALL verify the EventStatus of an Event before acting upon it. If the EventStatus potentiallySupersededTime has changed since last checked, and if the EventStatus type is “Partially Superseded,” clients SHALL check all Events from that function set instance that may supersede the original Event.
l) When a client receives an Event with the Specified End Time in the past (Specified End Time < Current Time), this Event SHALL be ignored. Note that the Duration Randomization is not used in this calculation.
1) For function sets with direct control, if the Event responseRequired indicates, clients SHALL POST a Response to the replyTo URI with a Status of “Rejected - Event was received after it had expired”.
m) When a client receives an Event and calculates an Effective Start Time (Start Time + Start Randomization) in the past and a Specified End Time in the future ([Effective Start Time < Current Time] AND [Specified End Time > Current Time]), the client SHALL begin the Event using the current time and the absolute value of Start Randomization. For response reporting purposes, the
start time SHALL be reported as the Current Time plus applied Start Randomization applied. For Event duration purposes, the Specified End Time SHALL be preserved, and any Duration Randomization attributes SHALL be applied to the abbreviated Duration.
n) For function sets with direct control, regardless of the state of an Event (scheduled or active), when a client detects an Overlapping Event condition, the Event with the latest creation time will take precedence over the previous Event. Depending on the state of the Event (scheduled or active), one of the following steps SHALL take place:
1) If the previous Event is scheduled and not active and if the Event responseRequired indicates, the client SHALL POST a Response (referencing the previous Event) with the Status of “The Event has been superseded.” After the Response has been successfully POSTed, the client SHALL ignore the previous Event scheduled.
2) If the previous Event is active, the client SHALL change directly from its current state to the requested state at the effective start time of the Overlapping Event. If the Event responseRequired indicates, the client SHALL POST a response (referencing the previous Event) with a Status of “The event has been superseded” at the effective start time of the Overlapping Event.
o) Randomization SHALL NOT cause Event conflicts or unmanaged gaps. To clarify:
1) For Successive Events clients SHALL use the earlier Event’s Effective End Time as the Effective Start Time of the later Event. Events are not reported as superseded and Clients should report Event statuses as they normally would for a set of Successive Events. Note: This means that a group of Successive Events without Duration Randomization will run successively using the initial Start Randomization for each of the Events in the group.
2) Randomization SHALL NOT artificially create a gap between Successive Events.
p) It is permissible to have gaps when Events are not Successive Events or Overlapping Events.
q) If multiple deviceCategory’s are identified for an Event, future Events for an individual deviceCategory (or a subset of the original Event) that cause an Overlapping Event will supersede the original Event strictly for that deviceCategory (or a subset of the original Event). Note: Rule f) applies to all Overlapping Events.
1) Those clients whose deviceCategory is not listed in the future Event but whose deviceCategory was included in the original Event SHALL continue to execute per the parameters of the original Event.
2) Rule c) continues to apply. Servers SHALL NOT edit the original Event but SHALL maintain all Events in their entirety.
3) A server SHALL set the potentiallySuperseded flag when the Event is superseded for any of the device categories and update the potentiallySupersededTime.
r) Servers SHOULD maintain and serve Events for the maximum Effective Scheduled Period. This applies even if the Event in question is cancelled, so as to support devices that may have previously received a copy of the Event from the server.
s) When an Event is removed from the server (e.g., due to limited storage space for the Event list) clients SHALL NOT assume the Event has been cancelled. Client devices SHALL only act on a cancellation as indicated in the rules above or an update to the Event’s Status attribute.
t) For DERControls, differing controls (e.g., opModTargetVar, opModTargetW) within DERControl Events are independent and are allowed to overlap or nest without superseding. If multiple controls are identified for a DERControl Event, future DERControl Events for an individual control (or a subset of the original Event) that cause an Overlapping Event will supersede the original Event strictly for that control (or a subset of the original Event). Note: Rule f) applies to all Overlapping Events.
1) Those clients whose control is not listed in the future Event but whose control was included in the original Event SHALL continue to execute per the parameters of the original Event.
2) Those clients whose control is listed in the future Event but whose deviceCategory is not listed in the future Event SHALL continue to execute per the parameters of the original Event.
3) Rule c) continues to apply. Servers SHALL NOT edit the original Event but SHALL maintain all Events in their entirety.
4) A server SHALL set the potentiallySuperseded flag when the Event is superseded for any of the controls and update the potentiallySupersededTime.
5) This rule also applies to the DefaultDERControl and DERControl Events should always be assumed to overlap the DefaultDERControl.
10.2.4 Randomization
10.2.4.1 Overview
The primary goal of randomization is to mitigate the effect of simultaneous actions by large groups of devices on distribution infrastructure (e.g., in response to a control signal). Adverse effects include voltage surges or sags, which can ripple through the distribution infrastructure and cause serious reliability problems or damage to electronic devices. Randomization is also useful to the orderly shutdown of operations prior to an event taking place to ensure the desired response occurs at the desired time. Use of randomization is appropriate and necessary to ensure the reliable and orderly operation of the distribution infrastructure for the related commodity (e.g., an electrical distribution network).
The randomization mechanism is suitable for any function set that signals devices to change behavior or causes actions to be taken in response. It is intended as a common object for all function sets. The primary function sets that use randomization are DRLC and Pricing. The DER function set may also make use of randomization. Note that other standards may be applicable to the underlying device and may provide their own protections that render randomization unnecessary (e.g., IEEE Std 1547™).
10.2.4.2 Randomization attributes
10.2.4.2.1 Introduction
Randomization consists of two signed attributes: randomizeStart and randomizeDuration. Neither, one, or both of these may be included as part of an Event.
Randomization is implemented using signed integer(s) to indicate whether a HAN device executes a control action before or after the start or duration (or both start and duration) of the related Event. Time granularity for randomization is one second.
The randomization values (randomizeStart and randomizeDuration) are generated by the creator of the Event. Clients acting on these Events use these values as bounds for generating a local random offset to the start and duration times, respectively, according to rules given below. Any device handling these Events and not operating on them SHALL NOT modify or apply them.
Examples of how to set the randomization parameters to accomplish different load management techniques can be found in C.21.
10.2.4.2.2 randomizeStart
The randomizeStart attribute represents the bound on the number of seconds to be used when randomizing the commencement of an Event. The device SHALL randomly select a number in seconds from zero to the randomizeStart specified for this event. Depending on the sign of the value (positive or negative), randomization SHALL be applied before or after the scheduled Start Time of the Event. If the value is negative, randomization SHALL be applied before the specified Start Time of the Event.
For example, if an Event is scheduled to start at 11:00 AM and has a randomizeStart value of “-300” (i.e., five minutes prior randomization), a client could randomly generate a number of “-120” (i.e., two minutes prior randomization) and begin the Event at 10:58 AM. If the value is positive, randomization SHALL be applied after the specified Start Time of the Event, causing the device to delay commencement of the Event.
10.2.4.2.3 randomizeDuration
The randomizeDuration represents the bound on the number of seconds to be used when randomizing the Duration of an Event. Devices SHALL randomly select a number in seconds from zero to the randomizeDuration value specified for the Event. Depending on the sign of the value (positive or negative), randomization SHALL be applied to increase or decrease the Duration of the Event. If the value is negative, randomization SHALL decrease the EffectiveDuration of the Event.
For example, if an Event is scheduled to conclude at 1:00 PM and has a randomizeDuration value of “−180,” a client can select to end the Event at 12:59 PM, indicating a negative 1 minute randomization. If the value is positive, randomization SHALL be added to the Duration of the Event, causing the device to delay termination of the Event.
10.2.4.3 Application guidelines/behavior
The values required to implement randomization represent relative time in seconds. Therefore, the signed values can be used to effect either positive or negative (relative to start time/duration) randomization. Clients that use fixed pseudorandom values SHALL scale the applied randomization based on the range indicated by the given randomizeStart or randomizeDuration. Stated differently, fixed pseudorandom values SHALL indicate a percentage of the randomizeStart or randomizeDuration to be applied. Fixed pseudorandomization is when a given device has a value that is applied for all randomizations. Manufacturers SHALL assure that fixed pseudorandomization values are random over a population of like devices.
Manufacturers SHALL assure that random number generators maintain a distribution of values over a population of like devices (e.g., by using differing seeds).
Clients that act upon Events SHALL support randomization. Clients SHALL apply randomization attributes when present in an Event’s attributes. Absence of a randomizeStart or randomizeDuration value in an Event indicates randomization is not to be applied to the commencement or duration of an Event, respectively.
Cancellation of an active Event SHALL cause clients to apply the greater of the absolute value of the randomizeStart attribute and the absolute value of the randomizeDuration to the abbreviated Event.
If an Event is in progress and an override occurs, the client SHALL respond to the override without randomization.
10.2.5 Multi-server
10.2.5.1 Overview
This subclause gives a description of how server and client devices should interact at the application layer when there are multiple servers of the same function set in the network, particularly in scenarios where there are multiple servers of a function set for the same commodity. There are several situations where this may occur; in some situations, one or more of the HAN’s servers may be coordinated beyond the HAN, but this is not required. These guidelines provide methods and guidelines to facilitate orderly and predictable operations.
10.2.5.2 Registration
One key element in a multiple server network is the registration of devices to function set servers. Devices need the capability of determining which function set servers in the network it should receive data from and act upon for a particular commodity per function set. Devices MUST complete the registration and service discovery process for each of the function set servers with which the user intends it to access information. See Clause 6 (security), 8.6 (function set assignments), and Clause 7 (service discovery) for more details.
There may also be function set servers the device discovers with which it is not registered, or the function set server does not allow devices to register. In this case, the function set server MAY provide “public” information (e.g., provided without explicit registration by the user) that devices MAY receive. Depending on the specific function set guidelines, this may also factor into the application guidelines for multiple function set server scenarios.
10.2.5.3 Time
Time coordination is an important aspect of multiple server scenarios. Each function set server that has a reference to time SHALL also serve its respective time to the HAN. Clients SHALL choose a primary time server in the HAN with which to align its internal time per the Time function set guidelines. See 8.6 (time function set) for guidelines on dealing with multiple time servers in the network.
10.2.5.4 Messaging function set
Devices can obtain text messages from many servers, service providers, and/or other devices. It MAY be very common to have multiple messaging servers in a HAN. For details of managing multiple messaging servers see 10.6 (messaging function set).
10.2.5.5 Pricing function set
Devices MAY obtain pricing data from many servers, service providers, and/or other devices. It may be very common to have multiple Pricing servers in a HAN. For details of managing multiple Pricing servers see 10.5 (Pricing function set).
10.2.5.6 DRLC and DER control function
There may be multiple DRLC and/or DER function set instances in a HAN, each operating independently. With the ability to act on instances from multiple servers that may not be coordinated in any way, there is the opportunity for conflicting/overlapping Events within a function set that the client will need to handle.
Clients SHALL only report acting on one Event at a time and SHALL NOT respond to multiple DRLC or DER servers that they are acting on multiple Events for that function set simultaneously. If clients are getting Events from multiple servers of the same function set they SHALL detect duplicate Events by comparing the mRIDs of the Events. If a duplicate is detected the client MAY respond to either, but, if requested, one response is REQUIRED.
When devices are registered to one or more DRLC servers, they SHALL NOT act upon any public DRLC servers that are present in the HAN or become available.
When devices are registered to one or more DER Control servers, they SHALL NOT act upon any public DER Control servers that are present in the HAN or become available.
Clients SHALL determine the primacy of DRLC and DER Control based on the following in order of precedence:
a) Servers SHALL indicate their primacy in the primacy element of the function set instance. See schema (IEEE Std 2030.5 supplemental material) definition of PrimacyType for possible values.
b) Clients SHALL prioritize execution of DRLC and DER function set Events with different PrimacyType attributes using the following guidelines:
1) 0 supersedes 1
2) 1 supersedes 2
3) 2 supersedes 3
4) If two instances are received with the same priority, then normal Event Rules and Guidelines apply (e.g., superseding based on scheduling).
c) If a client is executing an Event from one server and decides to execute an Event from a different server per the application guidelines, and if the superseded Event responseRequired indicates, the client SHALL send a response with “Aborted due to an Alternate Server Event” Response.status for the Event that was superseded. Likewise, if a client is executing an Event from one program and decides to execute an Event from a different program on the same server per the application guidelines and if the superseded Event responseRequired indicates, the client SHALL send a response with “Aborted due to an Alternate Program Event” Response.status for the Event that was superseded.
This mechanism and these guidelines allow service providers to coordinate among themselves or for regulatory/legislative entities to enforce coordination. Reputable service providers should appropriately self-select their PrimacyType attribute so as not to disadvantage the consumer’s participation in their contracted DR or DER Control service providers’ programs. This method does not prevent non-reputable providers from misrepresenting their communications.