< 上一个 | 内容 | 下一个 >

‌D.1 Pricing implementation guidelines‌

D.1.1 Introduction

This subclause discusses guidelines for implementing common service provider tariff rate designs and enabling HAN devices to match a TariffProfile.RateComponent.ReadingType with a meaningful metering value in cases where the Pricing and Metering servers may not be coordinated or match.

This subcluase assumes readers are familiar with the Pricing (10.5) and Metering (10.4) function set text. Readers may also wish to consult the WADL and schema (the supplemental material of IEEE Std 2030.5) for more detailed information.

D.1.2 Implementing common tariff designs

This subclause is intended to provide guidance to service providers and HAN server implementers on how to use the Pricing function set and its design flexibility in a way that encourages standard uses and practices. High-level description of the resources and attribute values are provided here; for detailed XML examples of the Pricing function set, see C.15. The following four tariff rate designs are discussed further in the text below:

 Flat rate

 Time-of-use tiers

 Consumption-based blocks

 Time-of-use (TOU) tiers with consumption-based blocks

All four designs will assume that Pricing information is only provided for the forward direction (commodity delivered), and is applicable for any flow rate (demand). This corresponds to a TariffProfile with a single RateComponent in its RateComponentList. This RateComponent would have the flowRateStartLimit and flowRateEndLimit attributes elided, and would link to a ReadingType with the flowDirection attribute set to “1”.

D.1.3 Flat rate design

The flat rate design assumes a constant price for a commodity over one or many billing periods. With no price differentiation based on the time of day or on the amount of the commodity already consumed, the flat-rate design requires only a single touTier and a single consumptionBlock. Therefore, the tariff’s RateComponent must link to a ReadingType with the following attributes:

 numberOfConsumptionBlocks = 1

 numberOfTouTiers = 1

Per the supplemental material of IEEE Std 2030.5, the RateComponent links to a TimeTariffIntervalList. The flat rate design only requires a single TimeTariffInterval in this list, though information for future seasons could be communicated by providing additional TimeTariffIntervals in the list (only one TimeTariffInterval can be active at a given time). Any TimeTariffInterval instance provided under a flat rate design must have the touTier attribute set to “1”.

Again per the supplemental material of IEEE Std 2030.5, TimeTariffInterval links to a ConsumptionTariffIntervalList. For the flat rate design there must only be one ConsumptionTariffInterval in the list. This ConsumptionTariffInterval defines the consumption price per commodity unit. The startValue attribute in this ConsumptionTariffInterval must be “0” and the consumptionBlock attribute must be “1”.

D.1.4 Time-of-use rate design

Most TOU rate designs consist of a repeating series of time-differentiated rates. These can vary over the course of a day, and the series may be different on weekdays and weekends. Pricing servers may be implemented and configured with functionality that creates repeating TimeTariffIntervals based on an internal schedule in order to minimize backhaul network traffic, but this is out of scope for IEEE Std 2030.5. For the HAN, such a Pricing server would supply a steady stream of pricing “events” with a defined commencement and duration. Pricing service providers and their servers are encouraged to provide enough Pricing information to cover the next 24-hour period since most consumer devices operate over this time scale. Pricing service providers are also encouraged to update their Pricing servers with the next sequential TimeTariffInterval instance at least four hours before its Effective Start Time.

For this TOU rate example, assume a daily three-tier (plus one critical peak pricing [CPP] tier) rate design with the following characteristics as shown in the table below:

Table D.1—TOU rate

Tier numbers are ordered by price from lowest to highest (though note that the price attribute itself will be found in the ConsumptionTariffInterval resource linked to by a TimeTariffInterval, not in the TimeTariffInterval itself); this is mandatory in IEEE Std 2030.5.

The TOU design provides price differentiation based on the time of day. However, as with the flat rate design, there is no price differentiation based on the amount of the commodity already consumed. In IEEE 2030.5 terms, this means that the TOU design requires two or more touTiers, but must provide only a single consumptionBlock. Using the above TOU example, the tariff’s RateComponent must link to a ReadingType with the following attributes:

 numberOfConsumptionBlocks = 1

 numberOfTouTiers = 4

Continuing the above example, consider a Pricing server configured as follows:

 Server provides 48 hours of price information.

 Price information is updated every midnight.

 The local time is 9 AM on 16 July 2012.

 There are no CPP events scheduled for the next 48 hours.

In this scenario, the server’s TimeTariffIntervalList will contain eight TimeTariffIntervals: one expired event, one active event, and six scheduled events. Each TimeTariffInterval will link to a ConsumptionTariffIntervalList, where each list, under a TOU-only design, contains one ConsumptionTariffInterval. As with the flat rate design, each ConsumptionTariffInterval must have a consumptionBlock attribute of “1” and a startValue attribute of “0”.

D.1.5 Consumption-based block rate design

In some jurisdictions (e.g., California, British Columbia, the United Kingdom), consumption-based block rate designs have been put in place to incentivize efficient consumption of a commodity with prices that ratchet up over the course of the billing period based on the amount of the commodity consumed. In other scenarios, typically for commercial and industrial (C&I) customers, the price charged per commodity unit consumed falls after some usage threshold.

For this consumption-based rate design, assume a five-tier design with the following characteristics in Table D.2.

‌Table D.2—Consumption-based rates

Block numbers are ordered by startValue from lowest to highest; this is mandatory in IEEE Std 2030.5. While the associated prices in this example also increase with each block number, this is not mandated by IEEE Std 2030.5. The above example corresponds to a ReadingType with the following attributes:

 numberOfConsumptionBlocks = 5

 numberOfTouTiers = 1

As with the flat rate design, a server using the block rate design may only have one TimeTariffInterval in the TimeTariffIntervalList linked to from RateComponent. That TimeTariffInterval could correspond to an entire billing period or longer. However, unlike the flat rate design, that one TimeTariffInterval will link to a ConsumptionTariffIntervalList containing multiple (five, in this example) ConsumptionTariffInterval resources.

Note that under a block rate design, as opposed to flat or TOU rate designs, a Pricing client cannot determine the active price solely from the Pricing server. The client will also have to query the corresponding Metering server to determine which consumption block is active.

D.1.6 Combined time-of-use and consumption-based block rate design

Yet other jurisdictions (e.g., California), have combined time-of-use and consumption-based rate designs to incentivize efficient consumption as well as shifting that consumption to times of lower system demand.

For this TOU with consumption-based rate design, assume a tariff structure that combines the previous two examples as shown in Table D.3.

‌Table D.3—Tariff structure

Using the above TOU + block example, the tariff’s RateComponent must link to a ReadingType with the following attributes:

 numberOfConsumptionBlocks = 5

 numberOfTouTiers = 4

Continuing the above example, consider a Pricing server configured as follows:

 Server provides 48 hours of price information.

 Price information is updated every midnight.

 The local time is 9 AM on 16 July 2012.

 There is a CPP event scheduled for 1 PM to 3 PM on 16 July 2012.

In this scenario, the server’s TimeTariffIntervalList will contain ten TimeTariffIntervals:

a) One expired event (Tier 1, present day 00:00:00 to 08:00:00)

b) One active event (Tier 2, present day 08:00:00 to 10:00:00)

c) Eight scheduled events, corresponding to:

1) Tier 3, present day 10:00:00 to 13:00:00

2) Tier 4 (CPP), present day 13:00:00 to 15:00:00

3) Tier 3, present day 15:00:00 to 18:00:00

4) Tier 2, present day 18:00:00 to next day 00:00:00

5) Tier 1, next day 00:00:00 to 08:00:00

6) Tier 2, next day 08:00:00 to 10:00:00

7) Tier 3, next day 10:00:00 to 18:00:00

8) Tier 2, next day 18:00:00 to day after next 00:00:00

Each TimeTariffInterval links to its own ConsumptionTariffIntervalList, and each ConsumptionTariffIntervalList will contain five ConsumptionTariffInterval resources with consumptionBlock, startValue, and price attributes set per the above TOU+Block rate.

As with the block rate design, under a TOU + block design a Pricing client cannot determine the active price solely from the Pricing server; the client must determine the active block from the associated Metering server.

D.1.7 Coordinated and uncoordinated Pricing and Metering servers

As with all function set servers in IEEE Std 2030.5, Pricing and Metering servers may be hosted by different service providers, served by the same provider on separate hosts, or coordinated or uncoordinated depending on the rules of the jurisdiction. This is problematic for certain tariff designs, particularly for consumption-based tariffs, which depend on usage accumulated during a given billing period in order to be able to provide accurate Pricing information. For example, in Texas, the retail energy provider (REP) owns the customer relationship and is responsible for serving Pricing information, but the transmission distribution service provider (TDSP) owns the meter and provides one standard meter configuration for all users, regardless of the REP, which may change depending on the customer’s preferences. Another use case is when customers do not have smart meters, but install their own and link their HAN to their electricity service provider’s Pricing server on its website.

This subclause recommends mitigation strategies and coping mechanisms to help Pricing and Metering clients provide users with actionable information to make informed decisions in the event that the ReadingType instance referenced by the Pricing server does not match any of the Metering server implementations available in the HAN. Devices that follow Pricing servers primarily for price responsiveness (e.g., smart appliances) do not need to follow these recommendations because the numberOfTouTiers and touTier attributes in the Pricing server’s ReadingType and TimeTariffInterval resources provide the guidance needed to optimize operational parameters.

The following rules are recommended for clients of Pricing and Metering resources and which aim to present a user with cost information about their usage or determine a nominal price for energy. These rules presume a client has performed service discovery and identified a suitable Metering server for its application (e.g., the premises aggregation point, PEV sub-meter). Rule #1 below assumes that the Pricing and Metering servers are coordinated. Rules #2 and #3 are meant to guide implementations in scenarios where the Pricing and Metering servers are uncoordinated.

 Rule #1: If the ReadingTypeLink URI in the Pricing server’s RateComponent object and the Metering server’s MeterReading object are the same, then they are a match.

 Rule #2: If Rule #1 is not satisfied, then the client should compare values in order to find the best fit.

a) The following attributes SHALL be exact matches in both servers’ ReadingType instances:

 commodity

 flowDirection

 kind

 uom

b) The following attributes SHOULD match in both servers’ ReadingType instances or be accounted for (e.g., accumulationBehaviour attribute in Pricing server may be “Delta Data” whereas the Metering server may only provide “Cumulative”; these can be matched with the appropriate device logic) or have at least one be designated as “Not Specified”:

 accumulationBehaviour

 phase

 Rule #3: If Rule #2 is not satisfied, clients SHOULD NOT display cost information to the user. Pricing clients SHOULD only display Pricing information. Pricing clients may indicate a mismatch between the Pricing and Metering server information and provide guidance to the user to contact his installer or service provider.

< 上一个 | 内容 | 下一个 >