Maximum Demand Tariff and its relationship with power factor and load factor

In this write-up, I summarize my findings of energy billing in Hong Kong and its relationship with Maximum Demand, Power Factor and Loading.

There are only 2 power utilities company in Hong Kong:

• Hong Kong Electric (HKE)
• China Light and Power (CLP)

They each have their own monopoly in their respective area. HKE takes Hong Kong Island, and CLP gets the Kowloon Peninsula, Lantau Islands the Northern Territories.

Image courtesy of CLP Power

Below are links to HKE and CLP's commercial and industrial tariffs 

• HKE's commercial, industrial & miscellaneous tariffs
• CLP's tariffs overview

HKE and CLP both provide this concept of "Maximum Demand Tariff" or MDT which has the potential to lower energy cost for high energy consumer. In the investigation summarized below, I focused on HKE because they provide a simpler MDT scheme (not necessary cheaper or better).

Hong Kong Electric provides an excellent explanation on how a customer will be billed if they opted for the "Maximum Demand Tariff"

As their example showed, opting for the Maximum Demand Tariff may not be beneficial for all customer. As HKE has pointed out on their website:

Maximum Demand Tariff consists of two parts, i.e. demand charge and energy charge. The demand charge is based on the maximum demand in kVA, while the energy charge depends on the energy consumption in Unit (kWh) of the month. Tariff charges are subject to a minimum of 100 kVA of the chargeable demand.
Maximum Demand Tariff is only beneficial to electrical installations with a high load factor. This applies to accounts of considerably high electricity consumption over a long period of time with a steady load. If these conditions are not satisfied, it is possible that the electricity charge could be higher under Maximum Demand Tariff than Commercial, Industrial & Miscellaneous Tariff.

Looking into the concept of Maximum Demand and the calculations, it will be most beneficial to customers with a more constant load over time and a high power factor. This is because the maximum demand charge, at least in the HKE's case, is calculated using the peak average apparent power in a 30 minutes period within the billing period (1 month).  

The observation where a customer with a more constant load will benefit by using the Maximum Demand Tariff billing method is pretty straightforward.  Since the peak usage is close to the average energy usage, the demand charge will be small relative to the energy charge.

Power factor plays a role in the calculation is due to the fact that Demand Charge in the "Maximum Demand Tariff" is measured in VA (Apparent Power) vs. W (Real Power) as in Energy Charge.

I did some Goolging around trying to look for the formula which HKE use to calculate their "Maximum Demand Tariff", but was unable to find it (Anyone with that information please drop me a note!).  I did some analyzing of HKE's Comparison Between Maximum Demand Tariff and Commercial, Industrial & Miscellaneous Tariff and played around a bit with their Maximum Demand Tariff Calculator, I deduced/guesstimate the billing formula/logic to be something like this:

maxdemand = consumption/1440/lf/pf

demandcharge = maxdemand * 44.2
if (maxdemand > 400) then
	demandcharge = 400*44.2 + (maxdemand - 400)*43.2
end

basiccharge = consumption * 0.861
if (maxdemand*200 < consumption) then
	basiccharge = (maxdemand*200)*0.861 + (consumption-maxdemand*200)*0.801
end

fueladj = consumption * 0.302

mdt = demandcharge + basiccharge + fueladj

Using the above function, I was able to plot a graph to visualized the costing under the maximum demand tariff billing method against the power factor and "load factor".

I define the loading factor as the following:

Maximum Demand = Consumption / 1440 / Load Factor / Power Factor

Load Factor is a ratio (unit-less) number between 0 and 1 which indicates how "well" distributed the load is across time.  

• A load factor of 1 indicates the power consumption is perfectly constant across time (at least all 30 minutes sample frame consume the same amount of energy during the billing period)
• A load factor of 0 indicates all power within the billing period is consume in 30 minutes time frame which the maximum demand is calculated

Here I plot a graph of the above formula in scilab for the power factor range 0.5-1.0, load factor 0.1-0.3 and power consumption at 120,000 kWh

I chose the range and values above to ensure the HKE's maximum demand tariff calculation examples were included in the plot. The two example are:

• MDT = HK$153,716.00 where load factor ~= 0.21929824..., power factor = 1
• MDT = HK$163,120.00 where load factor ~= 0.15151515..., power factor = 1

If we also make the assumption which typical loading factor is around 0.1 - 0.3 range, from the above plot we can see that we can reduce the energy consumption bill under the MDT scheme by:

• Improving the load factor: spreading the load across time especially during peak energy consumption
• Improving the power factor of the loading during the maximum demand period.

For the next step, it is probably worth quantifying the cost of improving the power factor of the entire loading of the energy consumer vs shifting loads from peak time to other times. Combined with the information in this post, we will be able to calculate the ROI on projects aimed at improving either the load factor and/or power factor.

Power Monitoring for DC Insight - Operation (InterMapper) - Developing the Modbus Probe

IDC Solutions from Australia was generous in providing us with a prototype of their pMon power monitoring hardware. The solution has Modbus TCP communication protocol and I am glad to say I have successfully integrate their solution into our DC Insight offering.

Since InterMapper does not support Modbus TCP out-of-the-box, I have to venture into using a command-line base probe to integrate the two.

The intention of this blog post is to summarize the development process and list out the resource I used (which I can later reference again if needed :)

First off, it is studying the Modbus protocol.  The Modbus Organization host the document - Modbus Application Protocl Specification v1.1b. After reviewing the specification to understand the low-level workings of the protocol, it is time to test and make sure the Modbus TCP functionality is indeed working on the device.  It appears there were not as many open-source/free tools available to do this test compare to SNMP.  In the end I found a free command-line tool, modpoll, and a simple GUI test client Simply Modbus (not free, but only US$60 for a single license).  I must confess, I didn't buy Simply Modbus TCP, since I am comfortable with using the command-line. But for those who like a GUI, give Simply Modbus a try!

I also looked into other open-source projects such as jamod and openscada. I was unable to get jamod to work, and openscada is really an over-kill for what I am trying to achieve.

This should all be relative straight forward except the documentation from IDC for the base register was incorrect!  The documentation claim the starting address is 401000, but in fact, it was just 1000. For those who know Modbus protocol, they should know right away something is wrong, since 401000 is greater than 65535, the 16-bit limitation on Modbus addressable space, but I was new and didn't know better.

With some trial and error, and some luck, I manage to find that the starting address is 1000.

In hindsight, it is now pretty clear why the writer of the document/manual might have thought it is 401000, because when you look at a typical modbus request, it will look something like this:

00 04 00 00 00 06 01 03 04 8A 00 02

"8A 00" highlighted is the starting address, but if you are not careful and including the byte before, you may actually think it starts with 4xxxxx!

After I sorted that out, it is time to pick the right method to integrate with InterMapper. At first, I thought a simple TCP probe might do the job, but after looking into the manipulation required, a command-line based probe is definitely the way to go.

I first thought of using Java to write a small program, but with my previous experience in building the RF Code  probes based on Java, I learned my lesson. To learn more about my lesson-learned and what is the disadvantage of using Java in this probe based application, I have wrote back to a question on the InterMapper-talk forum.  It just so happened someone requested for Groovy support to write InterMapper probes, I wrote back and gave my 2 cents.

The next logical choice would be to use InterMapper's support for python. I am pretty new to python, with some limited toying around in the past. I wrote a broken and primitive message board on Google App Engine when it first came, and later in my short dabbling with HomeTasty, which is also based on python.

Since I was doing some pretty low-level network programming, I studied the python socket api at the official python documentation. The write-up and examples there was sufficient for me to get the python integration going. After the python script was completed, the integration with InterMapper was pretty straight forward.

One last thing I want to share is the swapping of the higher-order and lower-order byte of a 32-bit value. Since modbus is a big-endian protocol and Windows/Linux is a little endian system, I have to do some bit flipping (shifting to be exactly, but I like the analogy to burger flipping in McDee). 

I haven't been flipping bits since my university days, so it took me a while to understanding the code suggested here and here after some googling.

The following code will swap a 32-bit value from "AA BB CC DD" to "BB AA DD CC".

swapped = (((swapme<<8)&0xFF00FF00) | ((swapme>>8)&0x00FF00FF))

And here is a screenshot of the InterMapper status window with power readings from pMon monitoring one of the feeds powering our centralized air-conditioner.

That's it for my little geeky adventure.  Now is time to iron out the details of the solution and prepare for the up and coming data center exhibition - Data Center Strategic 2011 in Hong Kong.

P.S. Here are some photos of the deployment.

Here is a picture of the pMon monitoring unit

Here is a picture of our fuse box.  There are 3 rows in this fuse box.  The open section shows a row of fuse for a single phase.   There is one more row above and below for the other phases.  The air conditioner is a 3-phase unit with a power feed from each phase.  I have clamp 3 feeds of the air conditioner to monitor our A/C power usage.

Here is a close up of the current transformer clamp on to a live power feed.

How SNMP probes in InterMapper determine lost packets or "No SNMPvX Response"

Here is an excellent write-up by William W. Fisher about the behavior of SNMP probes by InterMapper.  As we are building our DC Insight solution on top of InterMapper, a thorough understand of InterMapper is very important.
I would like to republish it here for those who are interested to have a deeper understand of how InterMapper behaves.

InterMapper polls devices by sending a request packet and receiving back a response packet. If InterMapper sends a request packet and does not receive a response within the specified timeout (usually 3 seconds), IM counts that packet as 'lost' and retries the request. If InterMapper's request fails to elicit a response three consecutive times, the device's status is set to down. (3 is the default)

With an SNMP probe, the lost packets are SNMP packets. There are three possibilities for where the packet was 'lost':

1. The request didn't reach the target device.
2. The target device did not generate a response within 3 seconds.
3. The response did not make it back to InterMapper.

The SNMP probe is slightly complicated by the fact that the final retry will be a ping packet instead of SNMP. We implemented it this way after finding that some devices do not reliably answer SNMP packets on time. For example, a busy router might leave SNMP packets unanswered, but answer pings immediately. (Responding to a SNMP query is more computationally intensive than answering an ICMP echo). A device that answers the final ping retry is marked as "No SNMP response".

If pings get through fine, but an occasional SNMP packet is lost to one particular device, my sense is that nothing is wrong with the network. I would advise that you increase the threshold for packet loss for that one device to 10% and leave it at that.

Let me know if this helps.

Regards,

Bill Fisher
Dartware, LLC

Source: http://www.mail-archive.com/intermapper-talk@list.dartware.com/msg03281.html