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

Contributing back to the open-source. A JSP taglib to read maven generated version values from MANIFEST.MF

Update 2011-08-09: Turns out it is not possible to externalized it into a separate taglib project.  I suspect it is actually reading the MANIFEST.MF from the taglib jar itself rather than the MANIFEST.MF file of the referencing project. The project from bitbucket have been deleted.
------
I have been searching the web to find a taglib which read the version information from the MANIFEST.MF file. Since this is very commonly used, I am surprise I was not able to readily find such a JSP taglib available!

This got to be a common problem since I found plenty of references on how to read version information from the MANIFEST.MF file. For example:

http://stackoverflow.com/questions/1906266/maven-2-how-to-package-current-project-version-in-a-war-file
http://www.flexthinker.com/2010/04/avoid-users-cache-when-deploying-new-versions-of-flex-app/
...

Instead of keep repeating myself, I decide to just quickly put one together and share it through the web. I have also threw together some quick instruction on how to use it on the bitbucket wiki https://bitbucket.org/lsiu/qds-commons-web/wiki/Home.

Here is the taglib in action:

The "1.0 (5956254adaaa+)" is just reading from the MANIFEST.MF file which in turn is populated automatically during the maven build process by the maven-war-plugin.

BTW, if anyone know of such a tag library, please give me a shout.  I will be happy to "unpollute" the web with yet another "roll-my-own-code" doing the exact same thing.

DC Insight - Analytic - Giving Data Center facility managers and operators what they want, when they want

Over the past couple of weeks, I was working closely with a data center operator to complete a cooling optimization project.  The customer deployed our DC Insight solution, which allow us to have a very high-density environment monitoring solution.  We have 2 sensors at each rack and 4 at each CRAC, as well as door sensors, dry contacts and fluid tags all deployed with no cabling required.

We have allowed our system to collect the "as-is" data for a week, then we went on optimizing the air-flow distribution of the data center, including installing HotLok blanking panels and KoldLok grommets.  We also re-arranged some perforated tiles to allow better air-flow distribution to the server equipment.

We then sit and waited for another week to allow our DC Insight solution to collect data.

Using the before and after data, we compiled a comprehensive report for our customer, confirming some existing suspicions, as well as discovering new interesting trends and potential risks.  Bottom line, this is a very data-driven process which allows data center operators to truly understand the environment which houses their mission critical systems.

The time has now come to streamline this experience.  This is where DC Insight - Analytic comes in. We are moving towards gathering the grass-root experience, and merge it with the best practice of today, to provide an Analytic platform for our data center users and operators.  This is still in alpha stage of development, but anyways, here is a screenshot:

Looks familiar? It is time to bring intuitive user-experience consumer had enjoyed for years to the world of data centers.

With DC Insight we now have all the pieces to make this happen:

• DC Insight - Integrator: The data collection platform to collect virtually any device with an electronically readable output.
• DC Insight - Operation: Utilizing the best-of-breed and proven platform of InterMapper, this provide operation team a familiar user-experience: map-in-map view, tiered notifications and alerts, acknowledgement  and device maintenance mode, multiple authentication source options, and admin/operator/read-only user role seperation.
• DC Insight - Analytic: The platform which brings all these together.  The number crunching and processing platform to bring an aggregated view and provide business intelligence to operators, managers and executives of today's data centers.

Wraps up a busy week in Beijing

With a project still underway in Hong Kong, I still end up heading to Beijing for a week.  Thanks to my colleagues in Hong Kong for holding the fort, we were able to handle some ad-hoc customer request regarding the project while I was away.

Thanks to my colleagues in Beijing, we were able to meet with 2 System Integrators in Beijing on such short notice.  We showcased our Wire-Free RFID environment monitoring solution, soon-to-be re-brand DC Insight. We received some positive response from the System Integrators and they even suggested they would start putting this in as part of the standard data centre design proposal!

I also spend a good amount of time training my technical colleague Mr. Niu on the system.  He is a pretty quick learner.  By the 3rd day, he has no issue setting up the demo and presenting it to the customer for our second meeting with another SI.  Boy, was I relieve as it was very difficult for me to present in my broken mandarin. As China present ample of opportunities, I see a strong need to really pick up mandarin quickly!

In the evening, we spend some time networking and socializing over dinner with some of my dad's friends and former associates in China.  Thanks to my dad for arranging these events.

With my broken Canton-Mandarin, I did try to chime in occasionally.  In the beginning, I was often met with these confused "what-the-heck-is-he-saying" look. A couple more beers, either I stop caring, or the conversation started to flow a little better. At the end of the day, we exchanged some contacts and email addresses.  Hopefully this well lead to some lasting relationships and opportunities for both parties on the motherland.

"Find X biggest object by retained size" function in jVisualVM help find memory leak in your program

After adding the component to interface RF Code Zone Manager with a custom InterMapper SNMP probe, I went about load testing it to ensure the stability of the solution. I have created a map of many many probe and set them to poll at 1 second interval.

During the load testing, I observed this steady growth in memory:

Not a good sign.

Good news is the jVisualVM has made finding the memory leak so easy!  I recall in the old days memory leak hunting use to be a pain without enterpricy tools such as YourKit.
I don't know when this was added to jVisualVM, but this function, "Find X biggest object by retained size", is tremendously helpful in finding the root cause of the memory leak!

Why is this function helpful? To understand how this function will help determine the root cause from memory leak, refer to this article, "Shallow and retained sizes", by the folks at YourKit.
Now just examine the classes with the largest retained size, and they are probably the classes giving you your memory leak problem!