10.9 Flow Reservation function set
10.9.1 Overview
This function set provides an interface for exchange of flow (e.g., charge or discharge) reservation events. Client devices of this function set include plug-in electric vehicles, distributed energy storage devices, and other managed loads that draw large amounts of power. Server devices of this function set include ESI, electric vehicle supply equipment (EVSE), and EMS. FlowReservations allow for the scheduling of high demand periods such as during fast-charging transactions, to make them run at different times and avoid high aggregated demand. Typically, energy rates have penalties, charges, or customer classes for different demand tiers, so it is usually least expensive to keep the maximum demand as low as possible. Distribution utilities may support this function set to minimize the maximum demand across the distribution system.
Servers accept FlowReservationRequests from client devices by exposing a FlowReservationRequestList for each EndDevice. Clients POST a request to transfer a certain amount of energy during a specific interval, at a specific rate. Servers create an associated FlowReservationResponse in the EndDevice’s FlowReservationResponseList. Servers may create superseding events to modify the interval within the requested timeframe and update the status to affect client behavior and distribute load across multiple reservations. To do this, the server must have knowledge of multiple clients, but can simply approve all requests unchanged if there is no other information.
10.9.2 List ordering
Table 48 —FlowReservation list ordering
Resource name | Primary key | Secondary key | Tertiary key |
FlowReservationRequest | interval.start (ascending) | creationTime (descending) | mRID (descending) |
FlowReservationResponse | interval.start (ascending) | creationTime (descending) | mRID (descending) |
10.9.3 Application guidelines/behavior
10.9.3.1 FlowReservationRequest
A client generates a FlowReservationRequest in order to trigger a FlowReservationResponse event from the server.
FlowReservation server and client devices SHALL be capable of internally storing and supporting at least one FlowReservationRequest instance and one FlowReservationResponse instance. FlowReservation server
and client devices SHOULD be capable of internally storing and supporting at least three unique FlowReservationRequest instances.
Clients SHALL NOT modify a FlowReservationRequest except to update the associated RequestStatus. Clients SHALL update the associated RequestStatus to Cancelled for any FlowReservationRequest that they want a server to subsequently disregard. A server SHALL return a 400 (“Bad Request”) response code if it receives a PUT of a FlowReservationRequest that contains changes other than RequestStatus.
Servers SHOULD remove FlowReservationRequests when the associated FlowReservationResponse expires. Servers SHALL retain FlowReservationRequests which have active FlowReservationResponses so that clients are able to cancel them if necessary.
10.9.3.2 FlowReservationResponse
FlowReservation server and client devices SHALL be capable of internally storing and supporting at least one FlowReservationResponse instance. FlowReservation server and client devices SHOULD be capable of internally storing and supporting at least three unique FlowReservationResponse instances.
A FlowReservationResponse SHALL be created in response to each FlowReservationRequest. If a server wants to deny a request, it SHALL create a FlowReservationResponse with duration equal to zero.
10.9.4 LogEvents
Table 49 —Flow Reservation LogEvents
LogEvent name | LogEvent code | LogEvent description |
FR_SCHEDULING_ERROR | 0x00 | SHOULD be issued if the server encounters an error and is unable to schedule reservations normally |