Thought energy from the people at Virtjoule

From the Blog

Jun
15

It’s 2 am. Do you know what your building automation system is doing?

Posted by randy on June 15th, 2012 at 12:56 pm

Summary

If you have a BAS (Building Automation System) you can’t assume that everything is always well.  Our experience has shown there can be numerous control problems with BAS systems even when staffed by full time employees (earlier blog article).  

In this article we’ll discuss problems with a Trane Tracker BAS used on a small 12,500 ft2 office and retail building in Niwot, CO.  

Without the knowledge of the building owner and operator or their HVAC service company, three out of the four Trane Voyager units were running 24 hrs a day multiple days a week, including weekends, when the building was not occupied.  The BAS programming interface was obtuse enough that even an experienced HVAC control technician failed to correct the problem on the first trip.  The problem was fixed on all four units on the second trip and our monitoring showed that the building owner would save over 5,600 hours of runtime over the course of a year.

This building is managed like many others where the building owner hires an HVAC service provider to provide varying levels of service, primarily to handle complaints and do some routine maintenance a few times a year.  The building is not large enough to justify a full time facility manager or maintenance person.

All four package units were the same Trane YCD120B3HCEB, a 10 ton package unit, installed in a small quad on the roof of this building.

After the first few weeks of monitoring, a clear picture emerged that suggested that all the units were running on flawed schedules.  Here’s a summary of what we found:

Unit 1:
Sunday through Tuesday – Unit ran 24 hrs each day
Wednesday – Saturday – 5:00 am – 11:00 pm

Unit 2:
Monday – Midnight to 7:30 pm
Tuesday – Friday – 4:30 am – 7:30 pm
Sat – on demand
Sun – 24 hrs midnight to midnight

Unit 3:
Monday – Midnight to 10:00 pm
Tuesday – Friday – Starts ranged from 3:00 am to 5:00 am with stops at 10:00 pm
Saturday – 6:00 am – 7:00 pm
Sunday – 24 hrs midnight to midnight

Unit 4:
Monday – Friday – 4:30 am – 6:30 pm
Saturday – Sunday – 3:00 am – 5:00 am and then on demand

To summarize that list, there were several units running 24 hrs per day for several days, several units with startup and shutdown times well before and after the building was occupied, and unexpected weekend runtime.

Keep in mind that this was a professional building that had some empty suites and the rest were 9-5 offices and a doctor’s office.  There was rarely any activity outside of normal business hours.

The byzantine BAS interface

This particular vintage of Trane Tracker BAS had a serial interface to the system.  The HVAC technician to had to “jack” into it with his laptop computer and was presented with a command line interface.  The building is divided into zones and groups and any particular suite would belong to both a zone and a group.

The HVAC service company for the building had only been in charge for about a year and was never asked to fully commission the building.  They had only been at the building a few times and never to fully explore the current BAS programming.  This particular BAS was old enough that their experience with it was out of date.

Everything is not as it seems

The technician discovered that there were several zones assigned to multiple groups, almost certainly caused by tenants moving in and out followed by layer upon layer of changes being made to the system.  Some of those groups had the obsolete schedules and somewhere along the line a programmer didn’t reconcile what was going on with all the zones and all the groups.  Who knows, perhaps someone did notice something amiss, but left it alone assuming the last person knew what they were doing and the problems kept stacking on.

Once we found this nest of issues we were sure that the problem would be fixed.  In the command line interface, the technician changed the schedules from things like 03:00 to –:– which was his latest understanding of how to zero out a schedule entry.

With much tedium through this interface, day by day, zone by zone, group by group, the technician dutifully found and “zeroed” out all the offending schedules by putting in –:–.  We wrapped up quite sure all was going to be well again.  It turned out it wasn’t.  Virtjoule was still detecting bad schedules, but this time it was a different set of bad schedules and all four units had the same bad schedule.  That was a disappointment, but also a clue.

The technician returned a few days later after conferring with a colleague who used to work at Trane and was an expert in these systems.  It was suggested that putting –:– to zero out a schedule entry left the Trane Tracker system assuming that it should continue whatever the last state was.  If the last state was that the building was occupied then it would go through the next schedule with the same state.  The new schedules were leaving the building in an “occupied” state at the wrong times.

The fix

Since it was not possible to tell this version of the Trane Tracker that a specific day was unoccupied, the technician had to set up very short run times on Saturday and Sunday such that the units would come on, but they would not stay on for very long.  Correcting all of the weekday schedules and double checking that the same zone did not belong to multiple groups cleaned up the other issues.  It became obvious that the new schedules were in place and correct.

Wrap up

Without the Virtjoule monitoring system, the schedule flaws programmed into this BAS would have gone unnoticed for years.  No one really knows how long it had been like that.  Left unchecked this could take years off the life of the equipment not to mention the extra utility expenses most often passed on to the tenants.

Even after a trained technician made changes, things were still not right.  Without the monitoring capability to actually know the machine was running, there would have been little resolve or patience to notice that the service call didn’t actually fix the problem.  Virtjoule not only found the problem, but it was able to verify that the problem hadn’t been fixed initially and was fixed on the second trip.

[Randy Cox - CEO and co-founder of Virtjoule - He is the software designer and analytics engineering for Virtjoule Sense sensors. He studied Chemical Engineering and Petroleum Refining at the Colorado School of Mines. You may contact Randy at: randy at virtjoule dot com]

Print Friendly

Leave a Reply


nine + 1 =

  1.  

    |