TOU stands for time of use. It's getting popular together with smart energy meters and advanced metering infrastructure (AMI). Basically it consists of 4 or more tariff rates which can be assigned to different times of the day.
Other terms for TOU are Time of Day metering (TOD) or Seasonal Time of Day (SToD).
Smart AMI meters are having a real time clock and a calendar, so the energy recording can be programmed time-based.
Before you start to make the most creative TOU structure it's useful to take a look at your historical records.
Smart meters can have one or more load profiles. Means, the meters are saving certain meter data in intervals (usually every 15 or 30 minutes).
The TOU tariff mainly applies to domestic meters. For industrial customer you will use a demand tariff structure.
Domestic direct connected meters can save load profiles, for the beginning interesting are the records of the transformer operated meters behind the distribution transformers and the consumption of your commercial customers.
What?
We recommend to equip all transformers with a CT-meter. With help of this meter you can compare the used energy with the sum-reading of all meters behind this transformer. This allows also nice tamper detection for hooking or full bypass. The end-customer can be tricky. If you don't have this set-up, you collect the load profiles from each meter individually.
If you want to introduce TOU for a certain region, you first merge all available consumption data for this region. Then you will have your regional load profile, showing the required power at certain times. Of course the profile is changing with the seasons and with additional consumers. So you need to monitor it on regular base.
Best praxis is to split the load profile in three segments.
- Off-Peak
A discounted electricity price during specific times when residential homes and industrial/business consumers use less electricity. - Shoulder
Some utilities use the term Mid-Peak. Usually it's the regular price per kWh like what is paid for a single rate tariff. - On-Peak
A higher price per unit than on shoulder tariff. During peak times you need eventually buy electricity on high prices from other power companies, eventually even from other countries.
How does it look like?
The graphics are for a better understanding simplified, as usual.
The diagram shows the result of your data acquisition, broken down to hours, for a whole month.
The X-axes shows the time of the day.
The Y-axes shows the required power. (MW or GW, depending on your region size).
To fulfil the customer demand, you are operating generators, or you buy from a power generation company.
The example here is for three generators.
Your fundamental power is usually higher than the off-peak demand, so you want to encourage your customers to shift a part of their consumption from shoulder- or on-peak load.
This will minimize the amount of expensive peak load.
You can hand out tariff diagrams, the customer will understand.
AMI time settings
| Time (hh:mm:ss) | Rate |
|---|---|
| 00:00:00 – 04:59:59 | rate 1 |
| 05:00:00 – 07:59:59 | rate 2 |
| 08:00:00 – 18:59:59 | rate 3 |
| 19:00:00 – 22:59:59 | rate 2 |
| 23:00:00 – 23:59:59 | rate 1 |
Billing system rate settings
| TOU Tariff | unit price/kWh |
|---|---|
| Rate 1, OFF PEAK | 25 ct |
| Rate 2, SHOULDER | 30 ct |
| Rate 3, ON PEAK | 40 ct |
Don't do this
Some utilities are asking for 8 TOU rates. This gives a more accurate billing picture but:
The end-user will be maximum confused.
So, up to now we have used three TOU tariff rates. This tariffs are assigned to different hours of the day. You can set-up as many different day-tariff structures as you like. For the beginning, two day definitions should be enough.
What about weekends?
AMI systems with TOU functionality also provide a week structure tables. Here you are assigning your defined days to a week. As the weekend has another power consumption profile you choose a day-definition matching with the customer behavior on weekends. Of course the weekend itself can be on any day of the week (e.g. Thursday half day + Friday, or Friday + Saturday).
It's also possible to change the TOU for each day of the week individually. Your end-customers will really appreciate the confusion.
And Seasons?
The TOU structure can change with the seasons. Also here is important that you have enough data to assign the defined TOUs price-wise to certain hours. Until you have evidence that your TOU model doesn't make you loose money, you'd better stick to already existing tariff models (e.g. day/night). Then you can introduce slowly things like weekends.
Next step will be seasons. Consider to make the TOU profiles first for summer/winter. With enough data you will become the utility master. The mapping for the seasons is similar to the week mapping (see illustration above). It follows calendar days.
And Special days?
With special days you can control the TOU rates for events like
- New Year
- Ramadan
- National Day
- Countrywide holidays
Special day settings will overwrite week- or seasonal settings.
How to forward the settings to all meters?
With modern AMI systems like our ClouESP you do all settings once or group-wise. The remote connection is updating the meters automatically at your desired date. The DLMS provides the feature of a second calendar in the meter memory. So you can send the updated calendar any time together with a switching date. Don't forget to inform your customers in case of TOU changes.
What do we learn?
TOU needs a lot of data analysis from the operative side. From marketing aspect it also requires trained staff. My suggestion is to do a TOU implementation very careful and not too fast.
The AMI system supports your evaluation with a bunch of reports. Still, you as operator understands your grid best. If you are unsure about the data interpretation, you can also start with TOU in a limited area (some thousand customer) for a trial period.
Are you already running time of use? Maybe you'd like to share your experience in handling and customer acceptance.
Thank you for reading.
Editor's note: This article was originally published in December 2019 and has been updated for comprehensiveness.
English
Français
Español
Русский
All comments are moderated before being published. Inappropriate or off-topic comments may not be approved.