Real-Time Monitoring and Diagnostic Solution for an HVAC System

Final Report

Senior Design Group 169Spring 2013

Team MembersAnthony Bellantoni

Greg CarmichaelJoe Grassi

Advisor: Prof. John ChandySponsor: Qualtech Systems, Inc.

Introduction

Many modern buildings contain heating ventilation and air conditioning (HVAC) systems. They are very complex electro-mechanical systems that heat or cool an enclosed area to a desired temperature. Being able to monitor these systems is vital for energy efficiency and to prevent problems that could occur in the system. Many HVAC systems have some form of Building Management System (BMS) so that errors can be detected should something incorrect occur. These BMS systems, however, can only determine where those errors occur. Using a program package created by Qualtech, Testability Engineering and Maintenance System (TEAMS), our model of the HVAC system would not only be able to show where the error occurs in a system but also the associated cost and time estimations it would take to fix that error. Also, the TEAMS program goes through the entire system and measures the probability that a particular error occurred because of the error in the sensor value. This can help find out exactly where the error occurs and the best approach to fix the problem.

Background

With increasingly complex systems being used in our buildings, it can be a challenging task to isolate an error, should one occur somewhere in the system. In order to be able to diagnose possible failures in a system, it is imperative that we first have a complete understanding of how the HVAC system works. From then, improvements can be made to the model from last year.

How HVAC Systems Operate

The main components of an HVAC system include: The Variable Air Volume (VAV) control, outdoor/return air intake, return/supply fans, an exhaust air outlet, air filters, a mixed-air plenum, heating/cooling coils, ducts, humidification/dehumidification equipment, and a terminal device.

The main function of an HVAC system is to process air in a building, vehicle, or other structure to maximize occupant comfort and safety. ITEB utilizes both return and outside air to supply the building. When the return air first enters the air duct it passes through smoke dampers. These are fire protection products which, if smoke is detected, will close and prevent smoke from entering and damaging the ductwork. The air hits the return fan which blows it into the next chamber. However if there is a problem with the quality of the air, exhaust dampers are activated and the air is blown outside.

Meanwhile, outdoor air is introduced to the chamber where the return air is delivered. This chamber is known as the mixed-air plenum and holds both return and outdoor air. The air proceeds through two separate air filters. These are primarily used to remove particles

from the air. However, in order to maintain clean air they must also remove bacteria, pollens, insects, soot, dust, and dirt. Different filters have different efficiency ratings based on the needs of the building. If too many particles build up on the filter it will become more efficient at particle removal, but increase the pressure drop through the system, reducing airflow. Too much buildup may also lead to clogged coils.

Based on the temperature of the air, it may either be cooled or heated. Heating and cooling coils are placed in order to regulate the temperature of the air being delivered. The cooling coil provides dehumidification as water condenses from the airstream. This process may only take place if the chilled fluid is maintained at a cold enough temperature. The condensate then exits through a deep seal trap under the coil. The heating coil increases the temperature of the air being delivered. This can be done either electrically or using steam. In our case, steam is used and set at a temperature which provides maximum comfort.

The air passes through a humidification coil which has the ability to increase the humidity in the building. Clean steam is used instead of treated boiling water. This is done so occupants are not exposed to chemicals. After air passes through the coil section, it reaches the supply fan where it is distributed throughout the building. Dampers are placed beyond the fan in order to control how much air volume is distributed to a particular zone.

Project Overview

Our project is a continuation of a project that was started last year. The goal of their project was to create a computer model by utilizing software designed by Qualtech to show every possible source of failures in the entire system. After that, real-time data would be compared to the desired values to determine whether or not there is a failure somewhere in the HVAC. Qualtech determined that the model the previous group created for the HVAC system in ITEB contained multiple errors and was incomplete. On top of that, they were unable to obtain continuous values read by sensors located in numerous areas in ITEB. Because the project was incomplete, our goal was to complete the model and accurately determine failures within the building’s HVAC system. To do this, we were required to use the same software that was designed by Qualtech to pinpoint failures. The software bundle is called TEAMS (Testability Engineering and Maintenance System).

Figure 1: Previous Group’s Designer Model

TEAMS Designer

TEAMS Designer is the part of the software that we used to build the model of the HVAC system. The program is a proprietary diagnostic modeling tool that measures only the failures that can occur in a given system. The program produces a tree diagram in which it takes into account every failure in the system, the probability of that failure, and the possible causes. There are three main components to the Designer model; modules, sub-modules, and failure modes. Each module is a main component that has multiple sub-modules. At the most basic level, each component has possible failures that can occur. Each of these failures has one or multiple associated functions. Functions determine the effect it will have on the rest of the system; should the specific component fail in that way. Each component of the system will also have an associated time and cost of testing for failure. This is useful because if there are multiple possible points of failure, the cheapest and most time efficient components can be tested first.

TEAMS-RT________________________________________________________________________________________________

TEAMS-RT provides diagnostics and system health monitoring in real-time as a compact reasoner running on any system’s on-board computer. It combines the TEAMS-Designer model, observed failures, and processes the results of on-board, built-in tests to perform diagnostics.

Diagnosing possible failures traditionally have their logic hard-coded in the software. TEAMS-RT uses a table or matrix containing relationships between on-board tests and the equipment failures. It uses every positive and every negative result to help pinpoint a possible failure. It is difficult and inefficient to check every failure manually (the number grows exponentially with the number of inputs). TEAMS-RT solves this problem, amplifies the diagnostic performance, and presents a tabular (matrix) solution that is easy to validate and maintain.

TEAMS-RDS________________________________________________________________________________________________

TEAMS RDS (Remote Diagnostic Server) is an online server that outputs and stores the diagnostic solutions. The server allows user interaction by web-interface by presenting the TEAMS-Designer model in a step-by-step diagnostic wizard. By using TEAMS-RT, a subsystem of RDS, real-time data can be analyzed by using a combination of algorithms to solve for diagnostic solutions. The user can then view the possible solutions along with the associated time and costs to determine what is the best way to solve the problem. This information is stored in TEAMS-KB (knowledge base) so that it can be accessed at any time after the model is complete. TEAMS-KB also stores previous repairs and failures that occurred in the system so that future diagnostics could be improved based on what needed to be repaired previously.

Process________________________________________________________________________________________________

The flowchart below in Figure 2 shows the process that was followed to obtain a working model. Schematics based on ITE’s HVAC system were used to create a model in TEAMS-Designer. By using the temperature and humidity sensors in the building, code was developed to read sensor values and determine if it reads a failure. If the value is not close to the set point, it is taken as a failure. Since actual sensor data was not obtainable, fake data was input so that tests and maintenance could be implemented. Once this code was developed, a client connection was made so that the TEAMS-Designer model could combine with TEAMS-RDS. This would allow diagnostic solutions of failures to be detected in the system. By using a sub-component of TEAMS-RDS known as TEAMS-RT, real-time analysis was achieved.

Figure 2: Flowchart of Our Procedure

Final Product________________________________________________________________________________________________

After researching how an HVAC works in the building we fixed and improved the previous year’s Designer model (Figure 1). We started from the ground up, replacing the repetitive and incorrect aspects from the past group. They only had one VAV for the entire building and considering the schematics that were available for us, we saw that there was roughly 30 VAV’s per floor (Figure 3).

Figure 3: Schematic of the third floor of ITE including zoomed in picture of one VAV. On the third floor there are 27 VAVs including both offices and labs.

Also, from our tour of ITE with Thomas Trahan, a UConn facilities employee, there were two air handlers separating the office side of the building and the labs. Figure 4 shows our final updated model. Our model only focuses on the basement, penthouse and third floor of ITE. We only implemented the third floor of ITE as the second and fourth floors would be the exact same. If future work were to be done on this project, it would be easy to copy the schematics used for the third floor to create the other floors.

Figure 4: Highest Tier of ITEB’s HVAC system in TEAMS-Designer.

Figure 4 shows the overall view of our TEAMS model that we developed for ITE’s HVAC system. TEAMS-Designer is a hierarchal system that contains sub-systems in each component shown. Within each component shown above, there are many sub-levels that have more in-depth functions about how the HVAC system works. For example, within each third floor schematic, there are multiple VAVs corresponding to the VAV’s shown in figure 3. Within the VAVs, are all of the possible ways that the VAV can fail. In our model, we have three components in each VAV that could fail; the reheating coil, the control valve and the air damper. Each of these components can fail two ways. The reheating coil can leak or be very dirty and the control value and damper can be stuck open or closed. The schematics below show the different levels of the system that were explained above.

Figure 5: Second Tier view of 3rd floor office wing consisting of multiple VAVs and their associated temperature and humidity sensors.

Figure 6: Third Tier view of a single VAV’s components.

Figure 7: Final tier within control damper of a single VAV showing possible failure modes.

Every system shown in figure 4 also has different sub-components and failures associated. Within our model, we have hundreds of possible failures that can occur. To organize this information better, we placed all components with associated failures into an excel spreadsheet so that we can easily determine what part is associated with what failure. Figure 8 shows a spreadsheet that we created to show each component and every failure that can occur in the system.

Figure 8: Spreadsheet of Components and Associated Functions/Failures

After the model was created, we had to develop code to parse the sensor values and determine if a failure occurred. The data that we were going to use to determine a failure was the temperature and humidity sensor values that are kept by facilities. Since we were unable to obtain real sensor data, we developed mock data in text files that could be run through our model. This way, if real data became obtainable, we could just parse the data into text files and implement it into our project. The way that we determine a failure was by checking the set points and seeing how far the data that we used deviated from the set point. Because there are different factors for why a room changes temperatures, you cannot assume automatic failures. Whether it is because a room fills up with people or someone opened a window, the temperature of the room could change dramatically in a few minutes. Because of these different factors, we did not consider the sensor to fail unless the temperature leveled off to a value different from the set point or it does not deviate back to the set point. Once we determined if a sensor failed, we separated the sensors that failed and the sensors that passed and placed them in two separate arrays. We then used an SDK file given to us by Qualtech to combine the model that we made with the failure code we

determined. This code links the model to an online web interface which combines our pass and fail arrays so that failures can be determined. The mock data that we used calculates one failure in a VAV. Figure 9 shows the health status of the model in RDS.

Figure 9: Health status of live RT sessions. The health status for our model is yellow as it has minor failures occurring.

The model that we are working in is the model with the yellow health status. This is because we have, in the code, determined one of the VAVs to fail. Figure 10 below shows the possible components of the model that have failed based on the VAV failing.

Figure 10: Suspect components based on a VAV failing.

As you can see in figure 10, RDS uses logical reasoning to determine the percent probability of each component failing. By knowing the probability of the failure, it is easier to isolate the location of the exact failure.

Another application of RDS is to assign tasks to technicians. Figure 10 shows the health status of the model that can be seen by a manager. The manager can assign a task to a technician to check one of the probable errors. The technician can then respond on RDS to whether or not they fixed the problem. If the component that they checked did not fail, RDS will then update the failed components with new percentages based on what the technician checked. From the model we created and the RDS web interface, diagnostic solutions can be made for the HVAC system in ITE.

TimeLine______________________________________________________________________________

Fall 2012

Week of 9/12 Assigned team & project – Begin researching HVACWeek of 9/19 Met with Qualtech contact Moises Soto – Learned TEAMSWeek of 9/26 Met with Prof. Pattipatti – Gain access to remote server & softwareWeek of 10/3 Met Eric Reynolds (last year team member) – Obtained schematics

Week of 10/11 Advised to focus on third floor; Email Facilities about Sensor dataWeek of 10/17 Met Tom Trahan & toured ITEB HVAC systemWeek of 10/25 Create guideline of components & associated failures spreadsheet

Week of 11/8 – 11/15 Completely remodeled last year’s designer modelWeek of 11/29 Continue trying to obtain sensor data;Begin thinking about codeWeek of 12/3 Contacted Prof. Pattipatti about obtaining sensor dataWeek of 12/6 Begin developing code; Resarch HVAC prices; Email about sensors

Spring 2013

Week of 1/31 Set meeting with Tom Trahan to review our HVAC modelWeek of 2/7 Created code to move a text file into an array

Week of 2/14 Met with Tom Trahan – Model had no errors so we move to codeWeek of 2/21 Learned and gained login access about TEAMS-RDSWeek of 2/28 Dicovered and fixed problem with blockers in modelWeek of 3/7 Received SDK file from Moises; Research HVAC pricing

Week of 3/14 Midterm Presentations; Advised to move forward w/out sensorsWeek of 3/28 Worked through some trouble on Failure Code with MoisesWeek of 4/4 Mock-Demoed with Chandy; Encountered remote server error

Week of 4/11 Fixed SDK model; Updated code for separate VAV failuresWeek of 4/18 Updated server name/port; exported designer model to RDSWeek of 4/25 Final Powerpoint Presentation; Reinstall TEAMS onto laptopWeek of 5/2 Connect TEAMS RT with RDS; Final Presentation in Gampel

Figure 11: Timeline of Accomplishments.

Figure 11 above displays brief week-by-week descriptions of what we accomplished throughout the year. For more in-depth updates, visit our webpage at: ecesd.engr.uconn.edu/ecesd169

Project Limitations________________________________________________________________________________________________

HVAC systems are extremely complicated mechanical systems that take a great understanding of fluid dynamics and heat generation. There is also hundreds of possible failures that could occur in a system that would make a temperature sensor read a false value. Through either the pipes rusting through the system or an electrical failure in the sensors, many different errors can occur that cannot be determined exactly from an incorrect sensor reading. For this reason, our project is focusing only on the high-level

failures that can occur in the HVAC system. We are focusing on the heat exchanger, air handler, and every VAV in the ITEB third floor.

The real-time sensor values for ITE are located on a protected server by UConn facility operations. After continual pursuit of trying to obtain access to the sensor data with almost no responses at all from the upper-management at UConn facilities we had to resign our efforts. We had to march on with our project without the actual data sensors; in place of the real sensor data we developed faux temperature data to implement into our model so that we may be able to at least demonstrate our model will work properly with any values.

Lastly, the cost and time pricing added into our designer model are only rough estimations of what our model would actually cost. Again, a problem contacting the upper-level management of UConn Facilities prevented us from obtaining the exact price estimations for the specific components in our system. HVAC systems are very complex and come in many shapes, sizes, and specifications an without the serial/model numbers of the components, along with an accurate pricing guide, we were forced to find similar models from online sources and estimate the differences.

Budget________________________________________________________________________________________________

There is no monetary budget associated with this project. All of the TEAMS software licenses were provided by QSI at no charge. All of the building schematics and servers to access the TEAMS software were supplied for free as well.

Conclusions________________________________________________________________________________________________

This project required us to use our knowledge and technical skills as engineers to solve a real-world problem. With the help of UConn facilities and our technical liaison, Moises Soto, we created a working and accurate model in TEAMS™-Designer that is capable of checking for, and isolating faults based on sensor value results.

During the development of this project, we learned that using TEAMS™ to its highest capability requires an expert technical background with the system. We were unable to obtain actual sensor results from facilities, however, our code can parse data from a text file that we created and implement failure results into our model to check for failures. If real-time data were to be obtained, it would be trivial to implement.

Although the overall requirements for this project have been met and completed there can still be some improvements to be made. Some improvements can be made by adding to what we have done while other improvements may involve taking completely new approaches to solving the problems faced. Should one decide to continue where we left

off, or decide to follow our steps and recreate our project, the following are some suggestions on how to improve upon our work:

For one, more floors of ITEB could be integrated into our system. A fairly simple task to complete (requiring little more than copying + renaming VAVs from our floor) but it would represent a much more accurate depiction of how the overall model actually works.

Another thing that can be added to our project is the actual temperature sensor data straight from UConn facilities. Referring back to our Project Limitations we were unfortunately unable to obtain the necessary access to gain these data points. Knowing now that talking to facilities would have resulted in not being able to have access to the temperature data they have, a possible alternative method would have been to purchase our own thermometers and humidity sensors and then record our own data independently.

Taking our project to the next step would involve deeper knowledge of the inner-workings of the HVAC system in ITEB. For our model we were advised to keep the possible failures of our system as general and basic as our systems allows. Due to our time constraints and background knowledge of only the electrical aspects an improvement would be to gather a more multi-disciplinary team to confer their knowledge for all aspects of the HVAC system. HVAC systems are as much a mechanical system as they are electrical and they involve highly complicated thermodynamic knowledge.

Additional Information________________________________________________________________________________________________

We would like to thank several people involved in the completion of this project: Prof. John Chandy, for his weekly guidance in his role as project advisor; Moises Soto, our technical liaison contact at QSI, for devoting hours of his time to helping us learn TEAMS; Thomas Trahan, Manager of UConn Facilities Zone Maintenance, for his help with understanding and accessing the HVAC system and its sensor outputs; Professor Laurent Michel and Artur Ulatowski for helping us obtain access to more schematics of the HVAC system in ITE; Erik Reynolds, for supplying and explaining his group’s model from the previous year; Stanley Nolan, Peter Luh, and Bing Wang for helping us try and obtain real-time sensor information; Prof. Krishna Pattipati, another important contact at Qualtech Systems Inc.; Diego Martinez, for helping set up our accounts to remote server as well as updating our TEAMS software.