Development and alpha testing of a cloud based automated fault detection and diagnosis tool for Air Handling Units

Automation in Construction 39 (2014) 70–83

Contents lists available at ScienceDirect

Automation in Construction journal homepage: www.elsevier.com/locate/autcon

Development and alpha testing of a cloud based automated fault detection and diagnosis tool for Air Handling Units Ken Bruton a,⁎, Paul Raftery b, Peter O'Donovan b, Niall Aughney c, Marcus M. Keane b, D.T.J. O'Sullivan a a b c

Department of Civil & Environmental Engineering, University College Cork, Ireland Informatics Research Unit for Sustainable Engineering, National University of Ireland, Galway, Ireland Innovation for Ireland's Energy Efficiency (i2e2), Ireland

a r t i c l e

i n f o

Article history: Accepted 14 December 2013 Available online 9 January 2014 Keywords: AHU Fault Detection and Diagnosis (FDD) APAR HVAC system energy efficiency BMS data acquisition On-going commissioning

a b s t r a c t Heating Ventilation and Air Conditioning (HVAC) system energy consumption on average accounts for 40% of an industrial sites total energy consumption. Studies have indicated that 20 – 30% energy savings are achievable by recommissioning Air Handling Units (AHUs) in HVAC systems to rectify faulty operation. Studies have also demonstrated that on-going commissioning of building systems for optimum efficiency can yield savings of an average of over 20% of total energy cost. Automated Fault Detection and Diagnosis (AFDD) is a process concerned with automating the detection of faults and their causes in physical systems. AFDD can be used to assist the commissioning process at multiple stages. This paper outlines the development of an AFDD tool for AHUs using expert rules. It outlines the results of the alpha testing phase of the tool on 18 AHUs across four commercial & industrial sites with over €104,000 annual energy savings detected by the AFDD tool. © 2013 Elsevier B.V. All rights reserved.

1. Introduction The contribution of buildings towards total worldwide energy consumption in developed countries is between 20% and 40%. This is expected to rise by an average rate of 1.5% per annum over the next 20 years [1]. Heating Ventilation and Air Conditioning (HVAC), and more specifically the operation of the Air Handling Units (AHUs), energy consumption accounts on average for 40% of an industrial sites total energy consumption[2] due primarily to the stringent cleanliness requirements that many of the industrial processes (clean-rooms, pharmaceutical production, etc.) require to be in compliance with international standards[3]. Approximately 50% of a commercial building's energy consumption is associated with HVAC energy consumption [4]. Overall, it is estimated that HVAC energy consumption accounts for 10 – 20% of total energy consumption in developed countries [1] with AHU associated energy use accounting for the majority of this. Historically, this consumption has been primarily associated with maintaining comfort conditions for occupants, but it is increasingly being consumed to maintain adequate operating environments for information technology (IT) equipment used in data centres. As IT infrastructure increases so too will the AHU energy consumption needed to maintain effective operation. Buildings rarely perform as well in practice as anticipated during design due to improper equipment selection or installation, lack of ⁎ Corresponding author at: Department of Civil & Environmental Engineering, UCC, College Road, Cork, Ireland. Tel.: +353 214902913. E-mail address: [email protected] (K. Bruton). 0926-5805/$ – see front matter © 2013 Elsevier B.V. All rights reserved. http://dx.doi.org/10.1016/j.autcon.2013.12.006

commissioning, or improper maintenance [5] to cite but a few reasons. Studies have indicated that 20 – 30% energy savings are achievable by recommissioning HVAC systems, and more specifically AHU operations, to rectify faulty operation [6]. Studies have also demonstrated, using a sample set of over 80 buildings, that on-going commissioning of building systems for peak efficiency can yield savings of an average of over 20% of total energy cost [5]. By coupling the re-commissioning and ongoing commissioning of an HVAC system into one demonstration study, savings of 44% of electricity consumption and 78% of gas consumption over a ten year period have been proven by the International Energy Agency (IEA) Annex 47, DABO Case Study[7,8]. Automated Fault Detection and Diagnosis (AFDD) is a process concerned with automating the detection of faults and their causes in physical systems [9]. IEA Annex's 25[10] & 34[6] were undertaken to develop and implement AFDD tools in real buildings. While testing these tools, researchers realised that the buildings they wanted to optimise had never actually worked properly. Hence, they decided that obtaining tools to detect new faults was important, but that it was even more important to commission buildings effectively, thus ensuring that initial faults were avoided on an on-going basis. Building Energy Management Systems (BEMS) are typically the repository of HVAC system and more specifically AHU operational data and are now commonly installed in commercial and industrial buildings [11]. Typically the cost of installing a BEMS is the biggest constraint to doing so. Approximately 45 – 75% of the associated cost is due to wiring (materials & labour) [12]. However, as the cost of wireless sensor networks decreases and their robustness and interoperability increase, so too will their application in building energy management systems

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

71

Fig. 1. Example of a typically undetected fault in a heating coil control valve.

[12]. This will serve to reduce the cost and expand the application of these systems still further. The availability of BEMS's offers the potential for AFDD systems with lower set-up costs than cases where a BEMS is not present.

2. AHU maintenance AHU operations are typically supervised and maintained by either an onsite facilities team or an offsite third party contractor. The number of AHUs in a typical HVAC system often outnumbers those supervising and maintaining the system by 20 to 1.1 This means that routine mechanical maintenance is typically carried out only when necessary due to an end user complaint, a machine breakdown or a breached alarm limit. The complexity of modern AHU control philosophies also commonly results in onsite personnel not having the required knowledge to root cause issues without costly external consultancy. Building operators are also typically overwhelmed by AHU data as the overlying monitoring and control systems have had little effort put into consolidating the vast quantities of information into a clear and coherent format [13]. Both top down (system level) and bottom up (component level) approaches are common methods of managing AHU operation in terms of optimising their energy consumption and achieving other operational targets. The top down approach is growing in its application though it is not yet commonplace. Many industrial and large/multi commercial sites now employ Monitoring & Targeting (M&T) approaches, energy performance indicators, and performance dashboards to manage site energy consumption. Typically these systems focus on the most significant energy end-uses, of which HVAC systems, of which AHUs are a member, are typically one. Structured energy management systems such as those in compliance with En16001 [14] or ISO50001 [15] promote this philosophy of energy management and are growing in their adoption. This top down approach is also being implemented in terms of fault detection on HVAC systems, with Wu and Sun describing a process of identifying faults in an HVAC system by looking at key characteristics of the systems rather than components [16]. The bottom up approach is far more common in practice. This method has developed from: breakdown maintenance of key AHU components, such as fans and filters; to time based maintenance; to today's not uncommon process of monitoring equipment based on its condition and then carrying out maintenance tasks as required. To take this

1 The 20 to 1 ratio is based on a survey of the number of pilot company facilities personnel versus the total number of AHUs which they maintain.

maintenance regime a step further, prognostic maintenance practices could be used by industry to manage the risks associated with unexpected equipment failure [17] focusing on preventative rather than reactive maintenance regimes. This change in maintenance philosophy is already in use in some industries with an international standard (ISO 13381-1) [18] lending direction, but its widespread adoption could be supported with AFDD tools. BEMS systems are also used to supervise the performance of AHUs in HVAC systems, raising alarms when upper or lower limits of operation are breached. However, they do not diagnose the root cause of these alarms, with few current BMS systems having fault detection or diagnostic capabilities [21]. Furthermore, when no alarm levels are breached, they do not detect underlying faults during what appears to be normal operation of these systems. A typical example is the hot water energy wasted by a passing heating coil control valve, as illustrated in Fig. 1 by the 5 °C rise in temperature across the coils in the AHU when both control valves are showing closed. This particular example typically goes unnoticed for long periods, as it is often possible for the AHU to maintain control of all set-points by using the cooling coil simultaneously to counteract the heating effect of the passing heating coil. 3. How can AFDD tools improve AHU maintenance and hence performance In order to ensure effective maintenance of an AHU, it must firstly be set up to operate effectively at the commissioning stage. As HVAC systems grow more complex, so too will the commissioning process required to ensure their initial efficient operation. If current trends continue this movement towards more complex systems will result in a more expensive and lengthy commissioning process. Xiao & Wang (2009) support this hypothesis stating that commissioning is labour intensive and that the future will be that of an automated lifecycle commissioning process embedded in the operation of the building management system[4]. Xiao & Wang (2009) also state that AFDD is a key means of achieving automated commissioning [4]. IEA Annex 47 [7] reviewed the operation of 18 such tools, concluding that automation is still uncommon during the commissioning process, and that future tools should be developed that are easily embedded in existing operational practices. Most commissioning activities are currently performed manually, as labour-intensive, once-off undefined processes upon completion of an installation. For commissioning to be truly successful, it must be embedded in the overall project process, and must follow a defined procedure in order to ensure it is effective and repeatable. It was for these reasons

72

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

that the IEA launched Annex 40 [19], with a view of developing, validating, and documenting tools for the commissioning of buildings and their services. This IEA study along with several others since [20,21], has concluded that there are essentially four ideal types of commissioning namely; 1) Initial commissioning — a first time process carried out on a newly constructed building; 2) Retro commissioning — a first time process on an existing building where no documented commissioning was previously carried out; 3) Re-commissioning — a process undertaken on a new or existing building to verify or improve performance; 4) On-going commissioning — undertaken continually to maintain, improve and optimise performance. During the initial commissioning phase of the AHUs in an HVAC system, their performance can be set to optimum levels. This would serve to ensure the AHUs operate to optimal “fault free” operation from the start of their lifecycle. This could be achieved using an AFDD tool, which identifies a number of areas which are not performing as intended during the design process. This could be as a result of over or under design of direct AHU equipment such as heating and cooling coils or as a result of a lack of integration with primary or secondary heating and cooling systems. It could also be due to changes in the intended end use of the air conditioned space that that AHU serves whereby the original intended purpose had been changed during later design stages without any alteration to the building systems servicing it. The AHU could hence be refined in its operation during the initial commissioning process to ensure it is operating as cost effectively as possible. During the Re/Retro commissioning stage, degradation in the performance of the AHUs in an HVAC system could be identified quickly and cost efficiently by an AFDD tool. Control strategies could then be altered to more adequately meet changing end use requirements. Degraded equipment such as damper actuators and valves could be replaced and damaged equipment such as damper louvers could be repaired or replaced based on the faults identified by the tool. An AFDD tool could be utilised very affectively as an on-going commissioning tool to bridge the gap between Re/Retro commissioning. Any degradation in the performance of the AHUs or its inbuilt components would be identified as and when they occur thus minimising the energy waste associated with each fault ensuring the system always operates in the most energy efficient manner possible. Once these items have been remedied, the AFDD tool could be used as an ongoing commissioning tool to ensure that any new faults in the system are detected effectively. IEA Annex's 25, 34, 40 & 47 [6,7,10,19] focused on the development of AFDD tools for use in the commissioning process. One such tool, DABO, is based on this two stage model whereby a commissioning module assists during the initial commissioning phase, while a reporting module operates in real time during normal operations. This reporting module highlights inefficiencies as they occur and offers the user a list of prioritised faults requiring their attention. This prioritised list is sorted in terms of criticality and relative cost, from no impact; meaning that neither comfort nor energy efficiency are impacted, to high impact; meaning that both energy and comfort are impacted. This information is then displayed to the user allowing them to make informed decisions as to which areas to remedy first. From 2006 to 2009, a total of 126 faults were identified using the DABO AFDD tool on a test building. Of these 91 were repaired based on their relative significance with 49 of these having energy efficiency implications. The development model utilised in the DABO tool is likely to be adopted commercially, as the information needed and the issues most likely found during initial commissioning are different to those present during normal operation. T.I. Salisbury & R.C. Diamond (2001) agree, having tested a proprietary AFDD tool, and conclude that initial commissioning should be carried out in order to ensure a fault free

starting condition before the introduction of an AFDD tool to monitor the operational phase of AHUs in an HVAC system [22]. Using this development model, current constraints in terms of maintenance resource availability and knowledge base could be overcome. The maintenance of large numbers of AHUs by a relatively small number of resources would now no longer be an issue as an AFDD tool could generate a list of prioritised action items focusing efforts where most required. The level of knowledge required to ensure that the AHUs in an HVAC system are operating correctly could be reduced as an AFDD tool could provide a reasoning engine to detect and diagnose issues automatically, only notifying the user when an issue has been diagnosed. Lastly, the issues associated with non-optimal control strategies or a lack of understanding of their operation could be addressed as an AFDD tool could monitor both the initial control setup and subsequent operation of the control algorithms, ensuring their robust and repeatable operation. 4. AFDD tool development Wang et al. [23] suggest that to be useful, AFDD must: • Be embedded into existing systems; • Be proven from field/pilot tests on real buildings; • Minimise the number of false positives to build user trust in the system; • Be rolled out in a cost effective manner; • Be generic enough to allow for large-scale implementation that is independent of platform/system (in order to ensure its widespread adoption in the industry). The primary objectives of the AFDD tool developed as part of this project were hence the development of a: • Data access layer which has the; Flexibility to work with any BMS type or age Ability to process BMS data into a generic form for post processing • A business layer which; Has the flexibility to work with any combination of sensors and components found in typical AHUs to ensure cross company compatibility Has the ability to use already available measurement without the need to install additional sensors to limit associated installation costs Delivers a low number of false positives/negatives in order to build confidence in the tool. • User friendly graphical user interface (GUI) which allows the; Evaluation of on-going performance of AHUs without in-depth domain expertise Quantification and prioritisation of the diagnosed faults to ensure return on investment is maximised through the repair of the most cost effective faults first. All of this also had to be achieved with a rapid set-up time per AHU to facilitate quick setup and maximum scalability across an organisation. It was also essential that the newly developed tool was tested on live AHUs in demonstration sites. Fig. 3 illustrates the overarching system architecture utilised to develop the AFDD tool.(See Fig. 2.) 4.1. Data access and processing 4.1.1. BMS data environment There are a number of issues that cause difficulty in obtaining BMS data and preparing and transferring it for analysis. Firstly, there are many different BMSs in operation in different companies, each most likely procured from different vendors with their own proprietary method for collecting, storing and archiving data. This can result in a significant level of heterogeneity in both the type of data storage and structure (e.g. a CSV file can have a single measurement per line

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

73

Fig. 2. 4 step commissioning process.

or several measurements across an array of columns) employed by the BMS. Common storage formats can vary from raw CSV log files (e.g. one comma separated value file for each sensor/or component in which each line in the file corresponds to a daily dump of all of the values stored on the controller) to enterprise-level Relational Database Management Systems (RDMS) (e.g. SQL, MySQL or Oracle). Secondly, implementing a robust data collection system for BMS data can be difficult due to the presence of legacy BMS software that is often out of sync with the latest technologies and standards. Due to the poor interoperability and integration methods exposed by most

BMS software, extracting and integrating BMS data can result in many data anomalies, including missing or null values, irregular timestamps (e.g. dd/mm/yyyy hh:mm compared to yyyy-mm-dd hh:mm), differing numerical representations (e.g. percentage measurements can be represented as an integer or as a floating point number) and spurious outliers in the data that need to be corrected or removed. Thirdly, measured data from AHUs is often not archived on many installations due either to a lack of understanding of the benefit and the process to achieve this by the system owner, or due to the storage required to archive the quantity of AHU data monitored by a typical

Fig. 3. AFDD tool system architecture.

74

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

Fig. 4. Data extraction process.

BMS. A generic data extraction process was hence incorporated within the AFDD tool to facilitate the transmission of BMS data from the client's server to a cloud-based web server, irrespective of the type of data collection, storage and archiving methods employed by the BMS software on each site. The data extraction component of the AFDD tool addresses these constraints by employing software design patterns and objectoriented principles, which provide a robust platform for developing extensible software components. 4.1.2. Data extraction process Fig. 4 provides a high-level view of the data extraction process. The purpose of this diagram is to highlight the significant components in the process, and conceptualise the collaboration that must take place to integrate data from BMS installations on remote sites. Table 1 provides a description of each high-level component in the data extraction process as shown in Fig. 4. Table 2 describes the interactions illustrated in Fig. 4 to convey their significance in the data extraction process. The ability of the AFDD tool to transform heterogeneous data in to a homogeneous structure enables it to work with disparate BMS installations. This functionality is realised using software engineering and Table 1 Data extraction process component descriptions. Component

Description

Task Manager

The inbuilt operating system service for scheduling periodical tasks. In this instance, it is used to initiate the console application. The console is responsible for marshaling data between the local data sources (e.g. BMS SQL Database) and the web service. The web service accepts inbound data from remote sites and persists the data in a cloud-based SQL Server database. This is a multi-tenancy database for storing measured data from multiple client sites (live database). This is a private database implementation that is used by the research team for ad hoc querying and analysis.

Console Processor

Web Service

SQL Server MySQL Server

object-oriented programming principles, such as abstraction and polymorphism. 4.1.3. Data parsing Fig. 5 provides a low-level view of the data parsing process that is used by the AFDD tool to interact with heterogeneous data structures (i.e. extracting data from disparate BMS installations). The actions in Fig. 4 provide an internal view of the functions that are executed in the ‘parse data files for each sensor’ action in Fig. 5. For simplicity and clarity, the data parsing functions in the diagram are limited to raw CSV log files. BMS data in CSV log files typically contain either a single measurement on each line, for which the VerticalFileParser function was developed, or several measurements on each line, spanning multiple columns for which the HorizontalFileParser was developed. The process begins when the Console object initiates the DataParserFactory object to create a new object that can be used to parse a data source. Several site-specific parameters are passed to the Table 2 Data extraction process component interactions. Action

Description

Start console application

The task manager starts the console application every 24 h to initiate a new. The console application contacts the web service to authenticate the site and returns what measurements should be collected. The console iterates through the collection of sensors that are returned from the web service and consumes the locally stored BMS data (i.e. the web service instructs the console where to find the data). This component is central to the collection of data from heterogeneous and disparate data sources. After the console has parsed the data for each sensor it transmits the parsed data to the web service for persistence. The web service persists the BMS data on the cloud-server. The web service persists the BMS data in a private MySQL server for ad hoc analysis.

Request site information

Parse data files for each sensor

Send readings for sensor[n]

Record sensor[n] readings in database (SQL) Record sensor[n] readings in database (MySQL)

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

75

Fig. 5. Data parsing process.

factory object, which were acquired from the Web Service during the previous step (Fig. 4). These site-specific parameters contain metadata about the sites data environment and preferences, including the location of the BMS data as well as information about its internal structure (e.g. the number of columns in the data source). The Factory object uses the meta-data to determine the object that is most suitable to parse a particular instruments data source (e.g. CSV file with multiple columns results in a HorizontalFileParser object being returned). Finally, the Console executes the ‘parse’ method of the chosen object to extract BMS data from the specified data source and transform it to a homogeneous data structure. The homogeneous and generic structure produced by the AFDD tool to store BMS data takes the form of a collection of Key/ Value pairs (i.e. Key = Timestamp and Value = Measurement). As the structure is populated with time and measurement data, inconsistent timestamps are eradicated by explicitly casting all timestamps to native DateTime objects [24] using the existing date string as input. Generic and extensible data extraction is achieved using an abstract interface to specify a contract that all data parsing objects must implement. More specifically, the DataParser interface ensures that each parsing object implements a ‘parse’ method that accepts a set of input parameters (i.e. site and sensor meta-data) and outputs data in a homogeneous format (i.e. Key/Value pairs). Enforcing a programmatic contract amongst parsing objects enables them to be used interchangeably and without discrimination, thereby promoting significant extensibility in the data extraction component of the AFDD tool. This extensible and interchangeable software design is built on the object-oriented programming principle of polymorphism, which enables objects of different types (i.e. BMS data formats and structures) to respond to the same calls (i.e. parse method), while behaving in a way that is appropriate to its type (i.e. single or multicolumn parsing). While data parsing transforms heterogeneous BMS data into a homogeneous and generic structure, it does not address all of the data related issues associated with different BMS system data. This is due to the fact that each parsing object adheres to the object-oriented programming principle of single responsibility, whereby each object's behaviour is limited to a single purpose or function. Using the single responsibility principle promotes maintainability and limits coupling and dependency between software components. As each parsing object focuses solely on structural transformation, other data anomalies such as differing numerical representations for percentage value for example, must be handled by data cleaning and transformation operations.

4.1.4. Data cleaning Data cleaning and transformation routines are undertaken by data extraction tools to promote reliability, consistency and confidence in the data being integrated. This type of computational task is synonymous with traditional data warehouses, which execute three cohesive tasks when integrating data — these are known as Extraction, Transformation and Loading (ETL). In the context of the AFDD tool, data parsing objects are responsible for data extraction, while the transformation, cleaning and loading operations are delegated to the Web Service. After the AFDD tool parses an instrument's data source, it transmits a homogenous data structure of Key/Value pairs (i.e. collection of timestamp/measurements) to the Web Service for persistence. The Web Service provides a façade that facilitates the encapsulation of data validation and cleaning processes, which eradicates data anomalies from the data before they are persisted. Each persistence request sent to the Web Service contains both measured data and an instrument identifier. These parameters enable the Web Service to associate the data with the correct sensor in the data repository and identify any data transformations that need to be executed on the incoming data before being committed to the data repository. A data cleaning operation in the AFDD tool is implemented as a parameterised mathematical string expression that is associated with an instruments meta-data during the commissioning of the tool. For example, the expression “{0}/100” utilised by data cleaning process transforms integer percentage representations to a decimal format in the data store. Implementing data cleaning operations at an instrument-level means that the AFDD tool can apply transformations to each individual sensor being monitored For example, a percentage measurement in the AFDD tool's data repository is represented as decimal (e.g. 0.8 represents 80%). If a particular instrument on a site records the same measurement using integer values (e.g. 80 represents 80%), the AFDD tool must run data cleaning operations to resolve the inconsistent representations. A data cleaning expression of {0}/100 can be used to transform the incoming data to decimal form, whereby {0} represents the input measurement. 4.1.5. Data loading Persisting measurements to the data repository are implemented using a Data Access Layer (DAL) that is encapsulated by the Web Service. The DAL uses the instrument identifier in the inbound parameter list to associate the measurements with the correct sensor and site data. Each key (i.e. timestamp) in the inbound data structure is used

76

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

Table 3 AFDD instrumentation nomenclature. Initial character

Description of the type of value

Unit

Subscript before comma

Description of location within the unit

Subscript after comma

Additional required descriptors.

C D F H P S

Measured CO2 concentration Controller signal: damper position Measured air flow rate Measured relative humidity Measured air pressure Variable frequency drive signal: fan speed

[ppm] [%] m3/s [%] Pa [%]

COO EXH FRO HEA HUM MIX

Cooling Exhaust (a.k.a. relief) Frost Heating Humidifier Mixing

DEW MEAN POST PRE RISE WEA

T V

Measured air temperature Controller signal: valve position

[°C] [%]

Error threshold

[varies]

Outside Reheat Return Supply Zone

SP

E

OUT REH RET SUP ZON

Dew-point Mean/average After fan Before fan Fan rise temperature Weather station/outside reference conditions Set-point

to form part of a composite primary key in the readings table, with the other component of the key being the instrument identifier. A composite primary key is used in the AFDD tool to uphold the integrity and reliability of the data repository by preventing duplicate entries for time-based measurements and insuring that missing timestamps (e.g. downtime on a client site could result in no measurements for a period of time) do not affect the loading operation. If a particular timestamp is not present in the data, a primary key for that particular time interval is not created. Therefore, if the timestamp and measurement are presented in a subsequent upload routine, the system can create a primary key and persist the measurement. The AFDD tool does not automatically fill missing data based on past records, though this could be an area for potential future research work. A new naming convention (Table 3) has also been developed to ensure that all data is generic allowing cross site analysis.

4.2. Fault detection business layer Correct identification of the mode of operation of an AHU is critical to identifying how each component should operate, and therefore, critical to performing AFDD. Approaches to date have focused on determining the operating mode of the AHU by identifying the actual operating mode from the outside air damper position, cooling and heating coil valve positions [25–27]. The tool described in this paper incorporates this approach but with some additions to increase effectiveness. The business layer developed for this AFDD tool has been developed with flexibility and extensibility in mind. Virtual data readings are calculated in poorly instrumented AHUs using available data to allow FDD analysis to be carried out. Conversely, where AHUs are excellently instrumented, new rules have been developed to utilise this “extra”

(beyond APAR) information to yield results. For example, where off coil temperature sensor data is available, the FDD business layer incorporated in this tool will identify if faults are present on each coil in the AHU rather than utilise only the supply and mix temperature readings to identify if issues are apparent only when certain conditions are met within the unit. This adds significantly to the diagnostic potential of the tool over previously available tools. Finally, the way in which the database schema and business layer have been designed means that the location of the equipment (coils etc) within the AHU does not adversely affect the analysis undertaken by the tool. For example, if the heating coil has been installed after the cooling coil or if a preheating coil has been installed in the AHU as well as a reheat coil, the business layer will still yield effective results as the naming conventional (Table 3) aligns instruments to their positions within the AHU allowing the business layer to only enact the required logic based on the AHU setup. Figure 6 details the location of all instruments supported by the rule-set. The business layer of the AFDD tool was developed using the APAR rule set [25] as a starting point. Significant modifications and improvements have been made to this rule set over the course of this project namely; • Expansion to account for other possible configurations of components and sensors: Frost coils; Reheat coils; Off coil temperature sensors; Before and after fan temperature sensor positions. • Expansion to include zone temperature and floating supply temperature control checks. New rules have been developed to check not only the supply temperature set point but also the zone temperature set

Fig. 6. Schematic of an AHU indicating all supported components and sensors.

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

•

•

•

•

•

•

point where applicable. If a floating set point is utilised by the control system, this live data field is extracted and stored in the database against which the supply or zone temperature is checked against in place of the static set point value. Expansion to include capability to detect faults on fresh air and not just return air AHUs. The business layer has been expanded to identify if an AHU is a fresh air unit, and to disregard those rules which do not apply it. A number of new fresh air specific rules have been added to the rule library to allow accurate analysis of this type of unit. These rules utilise the outside temperature in place of the mixed air temperature in return air units for coil actuation valve checks. The mode selection method has also been adapted to cater for full fresh air units. Expansion to account for faults that are apparent when the AHU is off: New rules have been developed to check for open valve positions and unnecessary (manual) fan operation during periods when the AHU has been identified as being not in operation versus the assigned time schedule as logged from the BMS system; New rules have been developed to check for unusually high or low off coil air temperatures indicating flow in the system when not required and/or passing actuation control valves on coils. Addition of virtual readings calculated using existing data allowing even poorly instrumented AHUs to benefit from the AFDD system analysis at least implementation cost; The temperature before or after a fan using an estimate for the rise in temperature across the fan; The mixing box temperature; The average outside air temperature. Development of a methodology to determine the “ideal” mode of operation utilising not only the component positions but also the outside conditions and comparing one against the other. The redevelopment of the rule structures to output numerical values in place of Boolean values to enable magnitude based measurement of faults and to facilitate future prognostic based analysis Development of an improved statistically based error threshold analysis

A key issue in the development of this AFDD tool was the use of a single, heuristically defined error threshold value that was applied to all of the rules. The purpose of this error threshold is to reduce false positives: where a fault is identified by the tool but none is present in the AHU (false positive) or vice versa (false negative). This error threshold is intended to account for all of the inaccuracies in measurements due to sensor error, sensor location, whether the measurement is taken using an averaging or point sensor, and the dynamic nature of AHU operation. A major issue with this approach is that the actual error associated with each rule is dependent on the number and type of measurements used in a particular rule. For example, a rule using just one measurement from an averaging temperature sensor should have a lower error threshold than a rule using 3 measurements from a variety of sensors. The approach used in this tool allows the user to define an individual error threshold associated with each sensor. The error thresholds for each sensor measurement used in a rule are then combined by root summation in quadrature to yield a rule-specific error threshold (Eq. (1)). ErrT rule

qffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi ¼ ErrT Instrument ð1Þ2 þ ErrT Instrument ð2Þ2

ð1Þ

Where; ErrTrule = Combined error threshold for a specific rule ErrTInstrument(n) = Heuristically defined instrument specific error threshold However, this still leaves the user with the problem of selecting the individual error thresholds for each sensor. A heuristically defined default value for a typical sensor can be used where no sensor specification information is available. The default values can then easily be modified

77

where there is a clear reason to decrease (e.g. averaging sensors used instead of single point measurements) or increase (e.g. poor sensor accuracy, an excessive number of false positives related to rules that use a particular measurement) the error thresholds. In addition to the above innovation, each rule outputs a ratio of the rule remainder divided by error threshold for that rule. This is in contrast to existing approaches which use a Boolean output. With this method, values greater than 1 indicate a fault with the relative values of the ratios used by the AFDD tool to define the magnitude of the fault as well as to enable future fault prioritisation and potentially prognostics. So in summary, once data is extracted from the BMS by the console application, a client side business layer performs mode checks, calculates virtual values, applies FDD rules, determines a diagnosis, prioritises and stores consequent results in a MySQL database. The business layer has been designed so that it can be broken down into rule set categories, several examples of which are described in Fig. 7. 4.3. Graphical user interface A GUI has been developed for the AFDD tool (Figure 8). The GUI has been built in Microsoft Excel using Visual Basic for Applications (VBA). This tool is very much a development tool which will be transitioned to a more scalable solution later in the project. The GUI allows the user to: • Set up new AHUs in the AFDD tool; • Modify set-up parameters • Visualise AFDD results The GUI automatically generates a schematic of the AHU based on the components and sensors that are present within the unit. Users can select any particular instance of time to be presented on this schematic. This feature allows the user to quickly view a representation of the AHU under any past operating conditions allowing fault instances to be analysed in more detail. All identified faults are listed by frequency of occurrence in the analysed period. Once a particular fault is selected, the GUI displays: • The measured and virtual data on the schematic for the most recent hour in which the fault occurs • A textual description of the currently displayed fault; • A graphical trend of the past 48 h of values relevant to that fault; • Options to move to other instances of that particular type of fault in the analysed period; • A list of possible diagnoses for the currently displayed fault; • A list of other faults which occur during the same hour; • The current operating mode of the AHU This allows for rapid viewing of individual faults, but still requires partial user input to root cause the fault at this stage of development. A number of potential methods to diagnose root causes are currently under development and will be tested as part of the beta testing phase of the project. 5. AFDD tool alpha testing 5.1. Design of test study The Innovation for Ireland's Energy Efficiency (I2E2) Technology Centre is an Irish government sponsored initiative. The I2E2 research focus is on energy efficiency improvements in manufacturing processes and supporting systems. The current research agenda focuses on a number of areas of common interest to group members, one of which is HVAC systems. The original scoping of the HVAC project started in January 2009 and the project currently involves two research providers and six industry partners. The main objective of this research is to provide an automated FDD tool that has been extensively tested on a range of different AHUs across a number of disparate industrial sites.

78

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

Fig. 7. Examples of the business rules.

Several hundred AHUs were available for selection as part of this project due to the scale of the industrial sites involved in this collaboration project. A number of characteristics were taken into consideration in order to select a number of representative units for the purpose of developing and validating the tool. As such, AHUs were selected with the following characteristics: • Different component and sensor layouts in order to ensure that the AFDD tool can be applied effectively and comprehensively;

• Varying levels of instrumentation in order to alleviate concerns regarding the level of instrumentation needed to perform FDD effectively; • The potential for duplication to ensure scalability to maximise savings. In addition to the selection criteria, return air units with mixing boxes were selected as these are more complex than full fresh air units and hence have the potential for more faults. Furthermore, mixing units incorporate all the components and sensors found in full fresh air systems ensuring that, once proven for return air units, the AFDD tool

Fig. 8. Screenshot of the GUI indicating an out of control zone air temperature.

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

79

Fig. 9. Example of one of the pilot site AHUs.

could be relatively easily expanded to apply to full fresh air units. Fig. 9 shows a picture of one of the pilot AHUs. Table 4, in which the industry partners are anonymous, describes the major characteristics of each pilot AHU, which were selected to offer varying component and sensory distributions.

5.2. AFDD tool test path In order to test the effectiveness and robustness of the AFDD tool developed as part of this project, it was decided to undertake initial alpha tests on four pilot sites supported and monitored by project researchers. This involved getting data automatically from each site to one remote database. All analysis and GUI interpretation were then undertaken in the research lab by skilled researchers who had developed the tool. This allowed the GUI development to be kept to a minimum as well as minimizing the work necessary to make the output from the tool understandable to someone who was not a member of the development team. This meant that results from the AFDD tool could be more quickly brought to the end user. After a successful period of alpha testing, it is envisaged that a period of beta testing will subsequently be engaged in with the same pilot sites, and possible other sites depending on the stage of development. This will entail the sites monitoring the tool themselves to garner user feedback on the operation of the AFDD tool.

5.3. Results 5.3.1. Energy savings identified by the AFDD tool The AHUs on several of the sites have been analysed in detail using the AFDD tool and a number of faults have been detected. Table 5 provides an overview of the major confirmed faults identified to date across the pilot AHUs and their associated energy consumption savings which totalled over €104,000 per annum. These faults have been verified by physical inspection and subsequent calculation using airside measurements. The cost savings associated with the faults were estimated assuming conservative annualised unit costs of associated energy and surveyed air flow rates through each AHU. 5.3.2. Individual site fault samples 5.3.2.1. Site 1: Fault instance 1: Passing heating coil actuation valve 5.3.2.1.1. Fault rationale. A temperature rise was picked up by the AFDD tool across both the heating and cooling coils though the cooling coil was recorded to be 26% open. There is no mix temp sensor in the pilot AHU under analysis, so a virtual mix temp was utilized. Hence there was a chance that the virtual mix temp could have been calculated too low in error if the return damper was stuck in position or leaking. 5.3.2.1.2. Root cause analysis. An airside temperature profile analysis was undertaken on the AHU by the research team. Surveyed figures are shown on the graphic from the AFDD tool in the black boxes in red

Table 4 Major characteristics of the pilot AHUs. Site

No. AHUs in pilot

Type

Design airflow [m3/s]

Type of zone(s) supplied

Operating hours per annum

BMS Software

Frequency of logged data

1 2 3 4

2 4 9 3

Constant volume Constant volume Variable Volume Variable Volume

14 20 13 8

Office & canteen Production area Manufacturing Floor Commercial office space

8760 8760 6240 6240

Trend Tridium Cylon Schneider

15 15 15 15

min min min min

Table 5 Savings identified by AFDD tool. Site

No. of AHUs in pilot

Faults identified by the FDD tool

Annual savings opportunities (approx)

Verification method

1 2

2 4

€66 k €23 k

Physical (airside) survey by the authors Physical (airside) survey by the authors

3 4 TOTAL

9 3

Passing heating coil, stuck damper actuator Damaged dampers, low supply temperature, passing cooling coil Damaged dampers Passing heating coil, design issues

€3 k €12 k €104 k

Physical (airside) survey by the authors Physical (airside) survey by the authors

80

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

Fig. 10. Site 1 AFDD tool fault screenshot.

text (Fig. 10). A temperature could not be obtained between the heating and cooling coils due to space limitations in the unit. The cooling coil was thus manually isolated and the temperature rise across the coils observed for a period of 15 min thereafter A 10 C rise across the “closed” heating coil was recorded over this period. The mixing box damper was also observed to be in a state of fatigue. 5.3.2.1.3. Savings projections. Based on the survey results and the data recorded by the AFDD tool, savings of approximately €48,000 per annum (thermal and electricity) are achievable by replacing the heating coil actuation valve and repairing the mixing box damper/actuator. 5.3.2.1.4. Other observations. A stuck return air damper was also identified during the alpha test period by the AFDD tool with annual cost savings of over €18,000 possible through its remediation. The AFDD tool also identified a lower than expected supply air temperature set

point. Further savings could be achieved by optimizing the supply air temperature to effectively match end use requirements when coupled with outside air temperature conditions. 5.3.2.2. Site 2: Damper fault instance 1: AHU 9: Leaking return damper 5.3.2.2.1. Fault rationale. A temperature rise was picked up by the AFDD tool (Figure 11) across the heating and cooling coils when the heating coil actuation valve was showing closed (0%) and the cooling coil was operational (27%). 5.3.2.2.2. Root cause analysis. A maintenance inspection by the research team confirmed the presence of a leaking return air damper due to damage to some of its louvers. 5.3.2.2.3. Savings. A saving of approximately €4900 per annum is projected based on the data leveraged from the AHU operation by the

Fig. 11. Site 2 AFDD tool fault screenshot.

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

81

Fig. 12. Site 3 AFDD tool fault screenshot.

AFDD tool and the site survey flow rate and air side temperature profile information. 5.3.2.2.4. Other observations. Cooling coils on a number of AHUs were found to be operating at capacity for prolonged periods. The control logic was altered to ensure that there were sufficient dead-band/PID control loops to reduce the chances of the cooling coil being called fully open. 5.3.2.3. Site 3: Control strategy issue 5.3.2.3.1. Fault rationale. The AFDD tool identified the heating coil as operating when the supply temperature was less than the maximum mix temperature possible with minimum fresh air (Figure 12).

5.3.2.3.2. Root cause analysis. The mix temperature was measured by site survey to be at a lower temperature than the sensor recorded. The fresh air damper actuator appeared to be closed to its minimum position from the information garnered from the BMS data. This leads to a conclusion that the mix temperature sensor was either faulty or the outside air damper was either damaged or the actuator was stuck in position at a more open position allowing a greater quantity of cold outside air into the mixing box. If this is not the case, then the control strategy should be revisited to ensure that free cooling/heating is maximized prior to opening the control valves. 5.3.2.3.3. Other observations. The supply temperature sensor was in a fault state

Fig. 13. Site 4 AFDD tool fault screenshot.

82

K. Bruton et al. / Automation in Construction 39 (2014) 70–83

5.3.2.4. Site 4: Passing heating coil actuation valve 5.3.2.4.1. Fault rationale. The AFDD tool identified a 5 C temperature rise across a closed heating coil (Figure 13). 5.3.2.4.2. Root cause analysis. The research team undertook a temperature profile analysis of the AHU at site 4. The cooling and heating coils were forced closed manually by the team and measurements were taken before and after the coils. A 5 C temperature rise was observed as the AFDD tool had measured thus verifying the presence of a passing heating coil in the AHU. Savings of over €4000 are achievable by replacing the actuation valve on the heating coil. 5.3.2.4.3. Other observations. A passing heating coil actuation valve was also identified on AHU3. The AFDD tool identified that there was a temperature pickup on the fresh air before it reached the heating coil. On inspection, AHU 1 takes its “fresh air” intake from the surrounding plant room at elevated temperatures when compared to outside air temperatures. This results in energy waste during the cooling season. Savings of over €8000 are achievable by remediating these issues. 6. Conclusions and future work The results from the Alpha testing phase of this project are very encouraging. A data access and processing application has been designed and installed on each of these sites. This application accesses and uploads data from each of four test sites to a central database each morning automatically. It integrates successfully with four different types of BMS system with very different data archiving methods. A business layer calculates virtual data points and detects faults in each of the 18 test AHUs across 4 pilot sites on a daily basis automatically. A GUI has been developed which displays the faults detected a day behind real time on each of the alpha test units at AHU level by fault frequency. Consequently, over €104,000 per annum of energy savings have been identified and verified by site survey across the four alpha test sites. These faults would most likely either not have been identified using the traditional maintenance practices of the companies in question or they would not have been identified unless an energy audit or review of the system was undertaken. Invariably this would have led to considerable energy waste. A commercial case therefore exists for the further development of this software. A number of general observations from the alpha test phase should be taken into account in the next phase of development and testing. • Manual interaction with the alpha test AHUs was identified as a major cause of energy inefficiency in the AHUs under observation. Supply and zone set points were found to be manually adjusted to overcome what were actually ineffective control issues or physical faults in the system. • It was difficult to obtain design details for most of the pilot AHUs. This was due to the age of many of the AHUs (resulting in a lack of documentation), frequent retrofits that have occurred on most sites (as the requirements for manufacturing environments change quite regularly), and difficulty in physically accessing the units in order to obtain measurements using temporary sensors and handheld devices. It is hence not practical to base any future analysis on design data as it is difficult to obtain. Based on the work undertaken in the alpha testing phase of this project, it is clear that a number of areas require further research and development in order to ensure the widespread application of a robust AFDD tool namely; • The AFDD tool must be a generic, cross-platform solution to ensure that data from any BEMS can be accessed efficiently. At present, the tools developed either by research institutions or commercially (e.g., PACRAT[28], DABO[8]) require substantial setup. This AFDD tool has tested a bespoke method of accessing BMS data successfully. Its testing will now be expanded to direct database access as well as to other BMS software to ensure its robustness and scalability.

• The error threshold analysis in this AFDD tool must be firmly based on robust statistical uncertainty approaches in order to minimise false positives and false negatives. A robust approach to error threshold analysis would ensure that the user could quickly gain confidence in the system. The error threshold methodology put forward in this paper must hence be tested and quantified in terms of documented success criteria. • This AFDD tool must be capable of supporting both the commissioning and operational phases on AHU operation. • It is critical that this AFDD tool be capable of prioritising fault actions based on their relative severity in order to aid the decision making process of fault repair and to ensure that the most process critical or economically advantageous faults are repaired first. • Finally, and possibly most importantly, it is critical that this AFDD tool is tested on a large number of actual AHUs in operating HVAC systems by the end users in a variety of buildings and organisations, with validated energy saving results, in order to build a commercial case for this process. There has been some activity in this area in the recent past [8], but not enough to support widespread adoption of the process. The beta phase of testing of this project will aim to address this shortfall by demonstrating the effective operation of this AFDD tool by third parties across multiple organisations. The results derived by the AFDD tool developed in this project will also be compared to those derived using existing methodologies such as APAR during the Beta phase of testing.

Acknowledgments This research was funded by Enterprise Ireland. The authors would also like to thank the Innovation for Irelands Energy Efficiency (i2e2) Technology Centre. References [1] L. Pérez-Lombard, J. Ortiz, C. Pout, A review on buildings energy consumption information, Energy Build. 40 (3) (2008) 394–398. [2] HVAC SWG - Spin I, [Online]. Available: http://www.seai.ie/Your_Business/ Large_Energy_Users/Special_Initiatives/Special_Working_Groups/HVAC_SWG_07/ 2007(Accessed: 23-Oct-2013). [3] ISO - International Organization for Standardization and ISO - International Organization for Standardization, “ISO - International Organization for Standardization”, [Online]. Available: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail. htm?csnumber=25052(Accessed: 23-Oct-2013). [4] F. Xiao, S. Wang, Progress and methodologies of lifecycle commissioning of HVAC systems to enhance building sustainability, Renew. Sust. Energ. Rev. 13 (5) (Jun. 2009) 1144–1149. [5] M.A. Piette, S.K. Kinney, P. Haves, Analysis of an information monitoring and diagnostic system to improve building operations, Energy Build. 33 (8) (Oct. 2001) 783–791. [6] International Energy Agency, Computer Aided Evaluation of HVAC system Performance, 342002. [7] International Energy Agency, Cost Effective Commissioning of Existing and Low Energy Buildings, 472010. [8] Daniel Choinière, Maria Corsi, “A BEMS assisted commissioning tool to improve the energy performance of HVAC systems”, in ICEBO, 2003. [9] S. Katipamula, M. Brambley, Methods for Fault detection, diagnosis and prognostics for building systems parts I & II, no. 2 m Int. J. HVAC&R Res. 11 (Apr. 2005). [10] International Energy Agency, Real time HEVAC simulation, 251996. [11] L. Gordon, Modelling user acceptance of building management systems, Autom. Constr. 11 (6) (Oct. 2002) 695–705. [12] W.-S. Jang, W.M. Healy, M.J. Skibniewski, Wireless sensor networks as part of a web-based building environmental monitoring system, Autom. Constr. 17 (6) (Aug. 2008) 729–736. [13] H. Wang, Y. Chen, C.W.H. Chan, J. Qin, An online fault diagnosis tool of VAV terminals for building management and control systems, Autom. Constr. 22 (Mar. 2012) 203–211. [14] CEN, “IS EN 16001”, NSAI, [Online]. Available: http://www.nsai.ie/Our-Services/ Certification/Management-Systems/EN-16001-Energy-Management.aspx. [15] ISO - International Organization for Standardization and ISO - International Organization for Standardization, “ISO - International Organization for Standardization”, [Online]. Available: http://www.iso.org/iso/catalogue_detail?csnumber= 51297(Accessed: 23-Oct-2013). [16] S. Wu, J.-Q. Sun, Cross-level fault detection and diagnosis of building HVAC systems, Build. Environ. 46 (8) (Aug. 2011) 1558–1566.

K. Bruton et al. / Automation in Construction 39 (2014) 70–83 [17] J.Z. Sikorska, M. Hodkiewicz, L. Ma, Prognostic modelling options for remaining useful life estimation by industry, Mech. Syst. Signal Process. 25 (5) (Jul. 2011) 1803–1836. [18] ISO 13381–1:2004 - Condition monitoring and diagnostics of machines – Prognostics – Part 1: General guidelines, [Online]. Available: http://www.iso.org/ iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=21841(Accessed: 23-Oct-2013). [19] International Energy Agency, Commissioning of Building HVAC Systems for Improved Energy Performance, 402006. [20] E. Mills, P. Mathew, Monitoring Based Commissioning: Benchmarking Analysis of 24 UC/CSU/IOU Projects, LBNL, Jun. 2009. [21] M. Baechler, J. Farley, A Guide to Building Commissioning, PNNL, Sep. 2011. [22] T. Salsbury, R. Diamond, Fault detection in HVAC systems using model-based feedforward control, Energy Build. 33 (4) (Apr. 2001) 403–415.

83

[23] H. Wang, T.-Y. Chai, J.-L. Ding, M. Brown, Data driven fault diagnosis and fault tolerant control: some advances and possible new directions, Acta Autom. Sin. 35 (6) (Jun. 2009) 739–747. [24] C# DateTime Object, [Online]. Available: http://msdn.microsoft.com/en-us/library/ system.datetime.aspx(Accessed: 23-Oct-2013). [25] J.M. House, H. Vaézi-Néjad, J.M. Whitcomb, An Expert Rule Set for Fault Detection in Air-handling Units, no. 1 ASHRAE Trans. 107 (Jan. 2001). [26] J. Schein, S.T. Bushby, N.S. Castro, J.M. House, A rule-based fault detection method for air handling units, Energy Build. 38 (12) (Dec. 2006) 1485–1492. [27] H. Yang, S. Cho, C.-S. Tae, M. Zaheeruddin, Sequential rule based algorithms for temperature sensor fault detection in air handling units, Energy Convers. Manag. 49 (8) (Aug. 2008) 2291–2306. [28] Facility Dynamics, “PACRAT”, [Online]. Available: http://www.etcc-ca.com/component/ content/article/21-Commercial-Office/2690-field-demonstration-of-pacrat.