Massive usage spike - Duke Energy large commercial account

Started by Chuck B. — 9 years ago — 17 views
Need some advice on a weird benchmarking situation. Client is a 85,000 sq ft office building in Cincinnati on Duke Energy rate LM-TOD. Their usage jumped from 6.8 kWh/sq ft annually to 11.2 kWh/sq ft over the past 18 months. That's a 65% increase with no major tenant changes or equipment additions. Historical benchmarking shows they should be around 7-9 kWh/sq ft for Class A office space. Anyone seen something like this before?
Chuck, that's a massive spike for office space. Out here with Avista Utilities, I've seen similar jumps when HVAC systems start failing gradually. Chillers losing efficiency, economizers stuck closed, or VAV boxes not modulating properly. The building operators don't notice because comfort is maintained, but energy usage goes through the roof. Have they done any HVAC commissioning recently?
Cindy's on the right track. I had an Entergy Arkansas account with similar issues - turned out their building automation system had a programming error that was running the HVAC at 100% capacity during unoccupied hours. The 11.2 kWh/sq ft definitely points to equipment running when it shouldn't. Check their interval data for nights and weekends to see if there's a baseload problem.
Helen makes a good point about interval data analysis. Up in North Dakota with Montana-Dakota Utilities, we use 15-minute interval data to benchmark occupied vs unoccupied energy usage. Office buildings should drop to 30-40% of peak consumption during nights and weekends. If they're staying above 60-70% of peak, you've got equipment running unnecessarily. What does their load profile look like?
Thanks for the suggestions. I pulled their Duke Energy interval data and you're absolutely right about the baseload issue. They're running at 78% of peak consumption during unoccupied hours, which is way too high. Normal office buildings should be around 40-45%. Something is definitely wrong with their HVAC scheduling or there's a major equipment failure they haven't identified yet.
Chuck, that 78% unoccupied load factor explains everything. I bet when you dig deeper you'll find either the BAS is malfunctioning or they have a chiller or AHU that's stuck running continuously. The good news is this should be a relatively easy fix once you identify the problematic equipment. Could save them $40-60k annually based on that usage spike.
This is exactly why we do interval data analysis on all our SMUD accounts here in Sacramento. Office buildings have very predictable load patterns, so any deviation from normal occupied/unoccupied ratios is a red flag. Chuck, once you get this fixed, consider setting up automated alerts through Duke's interval data portal to catch this type of problem faster next time.
Jennifer's right about the alerts. Alabama Power has similar interval data monitoring tools that can email you when consumption patterns change significantly. For benchmarking purposes, I also recommend tracking monthly kWh/sq ft and setting thresholds at 15-20% above historical averages. Catches these problems before they become $50k+ annual overcharges.
Update: Found the culprit. Their primary AHU serving floors 3-6 had a damper actuator failure that kept it running at full capacity 24/7 for the past 18 months. Building engineer never noticed because the space temperatures stayed comfortable. Simple $300 actuator replacement should drop them back to normal consumption levels. Thanks everyone for pointing me toward the interval data analysis.
Perfect example of why benchmarking is so valuable! A $300 part failure was costing them probably $3,000+ per month in excess energy charges. This is the kind of story we should be sharing with prospective clients to show the value of ongoing energy monitoring and benchmarking analysis.
Absolutely Arnold. I'm definitely adding this case study to my presentation materials. Clear ROI demonstration - $300 fix saves $36,000 annually. Chuck, would you mind if I reference this example in client meetings? Obviously won't use any identifying information, just the basic scenario and numbers.