NISTIR 6818

Using the Virtual Cybernetic Building Testbed

and FDD Test Shell for FDD Tool Development

Steven T. Bushby

Natascha Castro

Michael A. Galler

Cheol Park

U.S. DEPARTMENT OF COMMERCE

National Institute of Standard and Technology

Building Environment Division

Building and Fire Research Laboratory

Gaithersburg, MD 20899-8631

John M. House

Iowa Energy Center

Ames, IA
NISTIR 6818

Using the Virtual Cybernetic Building Testbed

and FDD Test Shell for FDD Tool Development

Steven T. Bushby

Natascha Castro

Michael A.Galler

Cheol Park

U.S. DEPARTMENT OF COMMERCE

National Institute of Standards and Technology

Building Environment Division

Building and Fire Research Laboratory

Gaithersburg, MD 20899-8631

John M. House

Iowa Energy Center

Ames, IA

Prepared for:

Architectural Energy Corporation

Boulder, Colorado

October 2001

U.S. Department of Commerce

Donald L. Evans, Secretary

Technology Administration

Dr. Cheryl L. Shavers, Under Secretary for Technology

National Institute of Standards and Technology

Karen H. Brown, Acting Director
Abstract

Advances in building automation technology have taken place for a variety of building services

including heating, ventilating, and air conditioning (HVAC) control systems, lighting control

systems, access control systems, and fire detection systems. In spite of these advances in technology,

many building control systems do not work as intended. It is evident that the industry needs to learn

how to take advantage of the new ability to interconnect traditionally independent systems in a

building. Commissioning, automated fault detection and new approaches to applying system

integration are all areas of active research. However, it can be difficult to conduct this research in

actual buildings because of the need to maintain comfortable and safe conditions for the building

occupants.

This report describes two enabling tools that have been developed to advance these research efforts.

It focuses on the use of these tools to develop and test automated fault detection and diagnostic

(FDD) technology for HVAC systems and their application in the area of Fault Detection and

Diagnosis. The two enabling tools are the Virtual Cybernetic Building Testbed (VCBT) and the FDD

Test Shell. The VCBT consists of a variety of simulation models that together emulate the

characteristics and performance of a cybernetic building system. The simulation models are

interfaced to real state-of-the-art BACnet speaking control systems to provide a hybrid

software/hardware testbed that can be used to develop and evaluate control strategies and control

products that use the BACnet communication protocol. The FDD Test Shell is a data-sharing tool that

was developed to enable side-by-side testing and comparison of two or more FDD tools and to

support the integration of information from multiple FDD tools.

Preliminary tests of some of the faults modeled in the VCBT are described in this report. The primary

goal of the tests was to quantify the impact of valve and damper leakage for typical air-handling unit

(AHU) with variable-air-volume (VAV) box configurations. In this study, testing revealed that

leakage through the outdoor air damper and a stuck open outdoor air damper fault have almost no

measurable impact on the operation of the system.

Key words: BACnet, building automation and control, direct digital control, energy management

systems, fault detection and diagnostics, cybernetic building systems

Acknowledgments

This work was supported in part by the California Energy Commission Public Interest Energy

Research (PIER) Program.
Table of Contents

1 INTRODUCTION ....................................................................................................................................................1

2 THE VIRTUAL CYBERNETIC BUILDING TESTBED.....................................................................................2

2.1 OVERVIEW .................................................................................................................................................................2

2.2 ARCHITECTURE..........................................................................................................................................................2

2.2.1 HVACSIM+ .....................................................................................................................................................5

2.2.2 BACnet Controllers ........................................................................................................................................7

2.2.3 Data Acquisition System...............................................................................................................................12

2.2.4 Center ...........................................................................................................................................................13

2.2.5 Graphical User Interface..............................................................................................................................15

2.2.6 CFAST ..........................................................................................................................................................17

3 THE FDD TEST SHELL .......................................................................................................................................18

3.1 OVERVIEW ...............................................................................................................................................................18

3.2 ARCHITECTURE........................................................................................................................................................18

3.2.1 The Coordinator Program............................................................................................................................19

3.2.2 Data Source Program...................................................................................................................................20

3.2.3 Using Reference Models with the Coordinator ............................................................................................20

3.3 DATA STANDARD.....................................................................................................................................................21

3.4 AHU TEMPLATE ......................................................................................................................................................21

3.5 INTERFACING TO THE COORDINATOR.......................................................................................................................22

4 FAULT MODELS...................................................................................................................................................23

4.1 AIR HANDLING UNITS..............................................................................................................................................23

4.1.1 Normal Operation.........................................................................................................................................23

4.1.2 AHU Faults: Implementation and Expected Impact.....................................................................................26

4.1.3 Open-Loop Tests of Select Faults .................................................................................................................34

4.2 VARIABLE-AIR-VOLUME BOXES .............................................................................................................................37

4.2.1 Normal Operation.........................................................................................................................................37

4.2.2 VAV Box Faults: Implementation and Expected Impact...............................................................................39

5 SUMMARY AND FUTURE WORK ....................................................................................................................40

6 REFERENCES .......................................................................................................................................................41
1

1 INTRODUCTION

Building automation and control systems are a special niche in the broad spectrum of distributed

computing and control technology. The features and capabilities of building control systems

change rapidly, driven to a significant extent by new computing technology developed for other

applications with larger commercial markets. State-of-the-art building automation and control

systems are characterized by powerful personal computer workstations and intelligent distributed

controllers that process complex algorithms quickly and efficiently. The advances in building

automation technology have taken place for a variety of building services including heating,

ventilating, and air conditioning (HVAC) control systems, lighting control systems, access

control systems, and fire detection systems. Adoption of the BACnet1

 standard [1]

communication protocol has made it practical to integrate building control products and systems

made by different manufacturers. With BACnet technology it is possible for building automation

and control products to exchange information and interact in creative ways that were not

practical in the past. A building that uses BACnet technology to integrate various control

systems and to connect the building systems to outside entities, such as utility providers, is

referred to in this report as a "cybernetic building."

In spite of these advances in technology, many building control systems do not work as intended.

In some cases they never did because the design, installation, or commissioning were not done

well. In other cases, inadequate maintenance has resulted in a deterioration of system

performance over time. Computer hardware and software problems sometimes contribute to the

difficulties. Because the ability to interconnect traditionally independent systems in a building is

a recent development, there is much that the industry needs to learn about how to best take

advantage of this kind of integration. Commissioning, automated fault detection and new

approaches to applying system integration are all areas of active research. However, it can be

difficult to conduct this research in actual buildings because of the need to maintain comfortable

and safe conditions for the building occupants.

To overcome the difficulty of conducting this kind of research using real buildings and outdoor

weather conditions, NIST has developed tools that emulate an entire building. This enables

building systems research to be conducted under controlled, reproducible conditions. This report

describes two enabling tools that have been developed to advance these research efforts. It

focuses on the use of these tools to develop and test automated fault detection and diagnostic

(FDD) technology for HVAC systems.

The two enabling tools are the Virtual Cybernetic Building Testbed (VCBT) and the FDD Test

Shell. The VCBT consists of a variety of simulation models that together emulate the

characteristics and performance of a cybernetic building system. The simulation models are

interfaced to real state-of-the-art BACnet speaking control systems to provide a hybrid

software/hardware testbed that can be used to develop and evaluate control strategies and control

products that use the BACnet communication protocol. The FDD Test Shell is a data-sharing

tool that was developed to enable side-by-side testing and comparison of two or more FDD tools

 

1

 BACnet is a registered trademark of the American Society of Heating, Refrigerating, and Air-Conditioning

Engineers, Inc. Use of trademark names does not imply recommendation of any commercial products by the

National Institute of Standards and Technology.
2

and to support the integration of information from multiple FDD tools. The objective of the work

presented here was to evaluate the effectiveness of the FDD tools for a variety of fault conditions

and a variety of weather conditions.

FDD is one of the new features that building controls manufacturers and service providers are

likely to offer in the near future; however, a considerable amount of development and testing of

FDD tools remains to be performed before this happens. The VCBT is an ideal tool for

preliminary testing because data representing both faulty and fault-free operation of HVAC

equipment and controls can be produced in a well-controlled simulation environment. The FDD

Test Shell further enhances this testing environment by enabling online access to the data

through a BACnet interface to the VCBT controllers. To gain access to the data, FDD tools need

only be capable of interfacing to the FDD Test Shell, which can be accomplished using a small

number of dynamic data exchange (DDE) commands. Thus, a single interface between the FDD

Test Shell and the BACnet controllers provides access to the data for multiple FDD tools. This is

also an attractive means of accessing data at field sites. Establishing the necessary

communication links first in a laboratory environment will help expedite the process in the field.

Section 2 of this report describes the architecture and capabilities of the VCBT in more detail.

Section 3 describes the FDD Test Shell and how it can be used to make data from the VCBT or

real buildings easily available for testing fault detection algorithms. In section 4 the development

of simulation models for commonly found faults in HVAC systems and the incorporation of

these models into the VCBT is described. Finally, in section 5 the significance of this work is

summarized and plans for the future use of the testing tools are described.

2 THE VIRTUAL CYBERNETIC BUILDING TESTBED

2.1 Overview

"Cybernetics" is defined as the science of control and communication of complex systems. In the

field of cybernetics, "intelligence" is determined by the observed conversations (i.e., interactions)

among various components making up the cybernetic system.

A cybernetic building system involves energy management, fire detection, security, and transport

systems. It may also include interactions with outside service providers, utilities, load

aggregators, and emergency services. The VCBT is a tool that provides a way to emulate an

entire building, including its various automation and control systems, in the laboratory. It

provides a way to examine the interactions of the various systems and to see how the building

reacts under adverse events, such as equipment failure or a fire. Tests can be conducted under

reproducible, carefully controlled conditions, including weather, without endangering the

comfort or safety of occupants in a real building. The VCBT can be used to test new concepts for

control strategies and prototype products in a way that is economical, efficient, and convenient.

2.2 Architecture

The VCBT is a collection of computer simulations that are distributed over several computers,

and coupled to each other and to commercial building controllers. The controllers are linked to

the simulations using a commercial data acquisition system that converts simulated values such
3

as temperatures, pressures, and flows into voltage or current signals that are wired to the

controller inputs. The control signals are digitized by the data acquisition system and fed back to

the simulations. The overall effect is that the controllers see data that looks like sensor

information from real building systems and the simulations respond to the control actions taken

by the controllers. Just as a flight simulator simulates an airplane in real time, the VCBT

simulates a building, the weather, the HVAC system, and the heating/cooling plant in real time.

The VCBT design details are based on experience gained from previous building system

emulator research [2]. A photograph of the data acquisition system and control hardware is

shown in Figure 2.1.

Figure 2.1. VCBT controller hardware and data acquisition system.

Figure 2.2 shows the components of the VCBT distributed simulation environment. The Center

is the heart of the distributed system. It serves as a repository for shared information that is used

to couple the simulations, exchanges information with the data acquisition unit, and controls

timing. Because real building controllers are used, each simulation must run in real time. The

HVACSIM+

 component is used to simulate the building shell and the HVAC systems. CFAST is

a fire simulation program that is used to simulate the effects of a fire in the virtual building. The

data logger is the communication interface to the data acquisition system and, indirectly, the real
4

building controllers. The Data Link provides access to a database used to configure the virtual

building simulations and investigate information-modeling techniques for representing building

system information. The database also contains simulation results that drive the user interface.

The graphical user interface (GUI) provides a three-dimensional representation of the building

and its component systems and is used to visualize the simulated systems and their responses to

control actions.

The common object request broker architecture (CORBA) is used to provide communication

between the distributed components of the simulation. CORBA is a vendor-independent, objectoriented architecture that provides a way to link computer programs across a network. The

HVACSIM+

 and CFAST simulation tools are implemented in FORTRAN. C++ wrappers are

used to provide an object-based interface to the simulation programs so that CORBA can be

used.

C/C++

CORBA

Java

CORBA

C/C++

CORBA

C/C++

CORBA

CORBA

CFAST

HVACSIM+

1

Center

Datalink

VR 

Engine

DataLogger

Controllers

C/C++

CORBA

HVACSIM+

2 C/C++

CORBA

HVACSIM+

3

BDS

C/C++

CORBA

SHELL

Coordinator

FDD

Tool

C/C++

CORBA

SDFM

Corba

Direct Wire

DDE

BACnet

Java

Relational

Database

Figure 2.2. Components of the VCBT distributed simulation environment.

The VCBT runs in real-time in a distributed, multi-platform environment. Each component can

potentially be run on a variety of machines, except for the data acquisition and control unit which

requires special hardware. The platforms used include Windows NT, Windows 95/98, and Sun

Solaris. The components use a variety of computer programming languages, including C, Visual

C++, FORTRAN, Java, and VRML.
5

2.2.1 HVACSIM+

2.2.1.1 General description of the HVACSIM+ program

HVACSIM+ stands for HVAC SIMulation PLUS other systems. It is a public domain computer

simulation program developed by NIST for studying the dynamic interactions between building

system components [3]. This program employs advanced equation solving techniques and a

hierarchical, modular approach. The simulation of an entire building/HVAC/control system

involves the simultaneous solution of a large number of nonlinear algebraic and differential

equations over large time periods using time steps on the order of seconds or smaller. The

modular approach is based upon a methodology similar to that used in the TRNSYS program [4].

Variable time step and variable order integration techniques are also used to reduce the amount

of computation time required for dynamic simulation. Stiff ordinary differential equations are

solved using a solving method based upon the famous Gear algorithm [5].

The HVACSIM+

 program consists of a main simulation routine, a library of HVAC system

component models, a building shell model, an interactive front end program, and post processing

routines. Most of the programs were written in Fortran 77. More recent updates contain specific

routines written in Fortran 90. Details of the HVACSIM+ program can be found in its manuals

[6-8].

2.2.1.2 Mechanical system component models

The virtual building models a three-story office building and its associated mechanical

equipment. Each floor of the building has three zones. The zones on a given floor are served by a

dedicated single duct (AHU) with variable-air-volume (VAV) terminal boxes. The AHU

dampers, valves, coils, actuators, ducts, and fans, and the VAV box dampers, coils, and valves

are represented by HVACSIM+ component models. In addition, all sensors are represented by

HVACSIM+ component models. Most of component models (TYPE routines) used in this study

were originally developed or revised during the course of ASHRAE 825-RP and described by

Haves and Norford [9].

Figure 2.3 is a schematic diagram of a single AHU and the interface of the AHU to the central

plant facilities. This figure illustrates the various dampers, valves, actuators, and fans that are

controlled. Simulated sensors that serve as inputs to the controllers for AHUs are listed below:

• Mixed air temperature,

• Outdoor air temperature,

• Outdoor air relative humidity,

• Return air temperature,

• Return air relative humidity,

• Return air volumetric flow rate,

• Supply air temperature,

• Supply air static pressure,

• Supply air volumetric flow rate.

The components depicted with dashed lines in Figure 2.3 are not currently modeled in the

VCBT.
6

Figure 2.4 is a schematic diagram of a single duct VAV box and its associated control points.

Simulated sensor outputs that are used as inputs to the controller for a VAV box are listed below:

• Zone air temperature,

• Volumetric airflow rate to the zone.

A A

A

A

C A

C C

C C C

C

C

A

C

Heating coil Cooling coil

Supply fan

Boiler Chiller Cooling tower

Supply air

Return air

Return fan Re-circulating air damper

Exhaust air damper

Outside air damper

Controller

Actuator

Figure 2.3. A schematic representation of a VCBT air-handling unit.

A C

A

C

VAV box heating coil

Supply air to zone

VAV box damper

Controller

A Actuator

Hot water

Figure 2.4. A schematic representation of the single duct VAV box.
7

2.2.1.3 Building Shell Model

A building shell model is included in the VCBT. It can be used to study climatic effects of

building location by varying the weather data used for the simulation. In the shell model, heat

gains or losses through the building surfaces (walls, ceilings, floors, doors, and windows) due to

the outside conditions such as outside air temperatures, solar intensities, and wind speeds are

computed. Conduction heat transfer functions are used to calculate conductive heat fluxes of

composite multi-layered surfaces [10]. Table 2.1 shows, as an example, the input, output, and

user-defined parameter variables associated with building surfaces.

Table 2.1. Building Surface Variables.

Variable Description

Inputs

TIA Indoor air dry-bulb temperature

TMR Mean radiant temperature

TOSINF Outer surface temperature of unexposed wall

FAHADW Shaded fraction of exposed surface

Outputs

TIS Inner surface temperature

SOLINT Integrated solar influx on surface

Parameters

IZN Identification number of zone

ID Identification number of surface

IEXPOS Internal exposure

0 = within zone, 1= between zones, 2=exposed to sun

ISTR Identification number of the construct

AS Surface area

ORIENT Azimuth angle of normal to surface & south

TILT Tilt angle: flat roof=0!, floor=180!

GRF Ground reflectivity

IROFS Outer surface roughness index: 1=stucco, ...

ABSOS Solar absorptance of outer surface

ABSIS Short wave absorptance of inner surface

EMITIS Emissivity of the inner surface

TRANSM Transmittance of the glass window

SC Shading coefficient of the glass window

2.2.2 BACnet Controllers

Commercially available BACnet controllers make up the building automation and control system

of the virtual building. The controllers are wired to patch panels that provide the connections to

the emulator. The controllers are connected to each other by various BACnet communication

networks. The intention is to eventually have control products from a variety of manufacturers
8

using all varieties of BACnet local area networks (LANs), connected into a single integrated

system.

Figure 2.5 shows the network topology of the current BACnet system. For each LAN, the figure

shows the type of network technology used and the BACnet network number. An Ethernet LAN

serves as the backbone to the system. It connects two operator workstations and the supervisory

controllers for the virtual building. These supervisory controllers provide scheduling capability,

alarm processing, implement reset schedules and also serve as routers to networks of unitary

controllers. The unitary controllers reside on ARCNET or MS/TP LANs. The Device Object

Instance_Number of each BACnet device is depicted as ID = XXX, where XXX is the instance

number. The medium access control (MAC) address of each controller on the ARCNET and

MS/TP LANs is also shown in the figure.

At the present time, the integrated building control system consists of HVAC controls and a fire

detection system. Products from three different companies are used. This virtual BACnet

building can be made accessible from outside of NIST via a BACnet PTP telephone connection

or using BACnet over IP features that allow access from BACnet devices anywhere in the world

via the Internet. Future expansion plans include the addition of lighting controls, vertical

transport, and access control.

Ethernet Backbone (network 10)

Controller/Router 1

(ID=100, MAC= X’09’)

 VAV Zone 1 VAV Zone 4

VAV Zone 2 VAV Zone 5

 VAV Zone 3 VAV Zone 6

AHU 1

(ID=101, X’10’)

(ID=102, X’11’)

(ID=110, X’04’)

(ID=104, X’13’)

(ID=105, X’14’)

(ID=103, X’12’) (ID=106, X’15’)

 Controller/ Router 2

(ID=200, MAC= X’01’)

AHU 3

(ID=210, X’03’)

 Router 3

(ID=211)

 VAV Zone 7 VAV Zone 8 VAV Zone 9

(ID=207, X’01’) (ID=208, X’02’) (ID=209, X’03’)

 Gateway

 Fire Panel

(ID=4001)

MS/TP (network 21)

ARCNET (network 31)

(network 41)

Workstation 1

 (ID = 199)

Workstation 2

 (ID = 299)

PTP

(Simulated)

AHU 2

MS/TP (network 22)

(X’02’) ( X’04’)

Figure 2.5. Network topology of the BACnet building automation and control system.

Control of air-handling units in the virtual building includes supply fan control, return fan

control, supply air temperature control, enthalpy economizer control, and supply air temperature
9

reset. Table 2.2 provides an example BACnet object database for the controller for air-handling

unit 1 (AHU 1). AI, AO, AV, BI, BO, and BV denote analog input, analog output, analog value,

binary (digital) input, binary output, and binary value objects respectively. There is some

variation in the BACnet object databases and control implementation details of the BACnet

components. These differences reflect the fact that product features vary from manufacturer to

manufacturer. The ranges of sensors and analog values in Table 2.2 correspond to design

assumptions about the building equipment operation conditions. These can be varied by AHU or

by zone.

Control of VAV boxes in the virtual building consists of damper control and reheat valve

control. The damper is controlled to modulate airflow to a zone, while the reheat valve coupled

with the reheat coil enables the temperature of air supplied to the zone to be increased. Table 2.3

provides an example BACnet object database for a sample VAV box controller.

Tables 2.2 and 2.3 illustrate the kind of detailed information that is available through a BACnet

interface to the VCBT. They also provide the object identifier details needed to access the data

using BACnet messages and the scaling details of the connection to the data acquisition system.

More complete descriptions of the AHU and VAV box control strategies are provided in section

4.

Table 2.2. Sample BACnet Air-handling Unit Controller Object Database.

Object Description Default Value Remarks

AI-0 Supply Air Temperature n/a 0 V to 5 V = -17.78 C to 93.33 C (0 F to 200 F)

AI-1 Supply Air Pressure n/a 0 V to 5 V = 0" to 5"

AI-2 Return Air Temperature n/a 0 V to 5 V = -17.78 C to 37.78 C (0 F to 100 F)

AI-3 Return Air Humidity n/a 0 V to 5 V = 0 % to 100 %

AI-4 Outside Air Temperature n/a 0 V to 5 V = -45.56 C to 65.56 C (-50 F to 150 F)

AI-5 Outside Air Humidity n/a 0 V to 5 V = 0 % to 100 %

AI-6 Supply Flow Rate n/a 0 V to 5 V = 0 to 20,000 L/s

AI-7 Return Flow Rate n/a 0 V to 5 V = 0 to 20,000 L/s

AI-8 Mixed Air Temperature n/a 0 V to 5 V = -45.56 C to 65.56 C (-50 F to 150 F)

BI-9 Supply Flow Proof n/a 0 V = Fan ON, 5 V = Fan OFF

BI-10 Return Flow Proof n/a 0 V = Fan ON, 5 V = Fan OFF

BO-0 Supply Fan n/a

BO-1 Return Fan n/a

AO-0 Supply Fan Speed 0 0 V to 10 V = 0 % to 100 %

AO-1 Cooling Coil 0 0 V to 10 V = 0 % to 100 %

AO-2 Heating Coil 0 0 V to 10 V = 0 % to 100 %

AO-3 Economizer 0 0 V to 10 V = 0 % to 100 %

AO-4 Return Fan Speed 0 0 V to 10 V = 0 % to 100 %
10

Table 2.2. Sample BACnet Air-handling Unit Controller Object Database -Continued

Object Description Default Value Remarks

AV-0 Temperature Ctrl Signal 0

AV-28 OSA Enthalpy 0

AV-29 Return Enthalpy 0

AV-40 Min. Return Fan Speed 20

AV-41 Min. Supply Fan Speed 20

AV-42 Supply/Return Flowrate Differential 200

AV-43 Dehumidifying Supply Temp. Setpoint 50

AV-44 Current Supply Temp. Setpoint 0

AV-45 Supply Temp. SP Reset Loop 0

AV-46 Highest Cooling Signal (from VAV's) 0

AV-47 Supply Pressure SP Reset Loop 0

AV-48 Current Supply Pressure Setpoint 0

AV-49 Highest Need More Air Signal (from VAV's) 0

AV-50 Supply Pressure Setpoint - Warmup 1.4

AV-51 Supply Pressure Setpoint - Hi Limit 2

AV-52 Supply Pressure Setpoint - Lo Limit 0.2

AV-53 Supply Pressure Setpoint - Manual/Startup 1

AV-55 Supply Temp. Setpoint - Hi Limit 65

AV-56 Supply Temp. Setpoint - Lo Limit 50

AV-57 Supply Temp. Setpoint - Manual/Startup 60

AV-58 Supply Temp. Setpoint - Warmup 160

AV-60 Supply Temp. Low Limit 50

AV-66 Econ Min. Position % 15

AV-80 Humidity Hi Limit 60

BV-20 Alarm Reset OFF

BV-26 Supply Fan Alarm OFF

BV-28 Return Fan Alarm OFF

BV-32 Economizer Lockout Status OFF ON = Econ. locked out

BV-40 Occupied Command OFF Starts AHU, Econ. to Min. Position

BV-41 WarmupCommand OFF Starts AHU, Econ. stays closed

BV-43 Return Fan Proof OFF Transferred from BI-9

BV-46 Supply Fan Proof OFF Transferred from BI-10

BV-47 Supply Pressure Setpoint Reset Switch OFF ON = Autoreset, OFF = Manual

BV-48 Supply Temp. Setpoint Reset Switch OFF ON = Autoreset, OFF = Manual

BV-49 Dehumidifying OFF Indicates system is dehumidifying
11

Table 2.3. Sample BACnet VAV Box Controller Object Database.

Object Description Default Value Remarks

AI-0 n/a not used

AI-1 Room Temp. n/a 0 V to 5 V = -1.11 C to 54.44 C (30 F to 130 F)

AI-2 Discharge Air Temp. n/a 0 V to 5 V =-4.44C to 87.78 C (40 F to 190 F)

AI-3 Airflow Rate n/a 0 V to 5 V = 0 to 4000 L/s

AO-0 Damper Command OFF 0 V to 10 V = Full closed to full open

AO-1 Heating Valve Command OFF 0 V to 10 V = Full closed to full open

AO-2 OFF not used

AV-0 Heating Signal 0

AV-1 Cooling Signal 0

AV-4 Desired Airflow - Cold 0 CFM

AV-6 Occupied Heating Setpoint Offset 0

AV-7 Occupied Cooling Setpoint Offset 0

AV-9 Cooling Damper Position % 0

AV-10 Need More Air - Clg 0

AV-14 Heating Valve Position % 0

AV-20 Windsock - Cold ( 0 to 1) 0

AV-64 Cooling Damper Time 60 seconds

AV-65 Heating Valve Time 60 seconds

AV-66 Reheat Air - L/s 300 Desired airflow when htg valve full open

AV-67 Max Airflow - L/s 1000

AV-68 Min. Airflow - L/s 100 Min. air applies only when occupied

AV-90 Occupied Setpoint 72 Limited by AV-91 and AV-92

AV-91 Occupied Setpoint - Hi Limit 80 Limit for AV-90

AV-92 Occupied Setpoint - Lo Limit 65 Limit for AV-90

AV-93 Cooling Offset 1

AV-94 Heating Offset 1

AV-95 Unoccupied Cooling Setpoint 85

AV-96 Unoccupied Heating Setpoint 55

AV-97 Afterhours Timer Limit 0 Duration for Microtouch

AV-98 Afterhours Timer (hr) 0 Automatically counts down to 0

AV-99 Current Cooling Setpoint 0 Calculated

AV-100 Current Heating Setpoint 0 Calculated

AV-101 Microset Room Temp. 0 Use DDC to transfer AI to this AV

AV-102 Humidity from Microset 0

AV-103 Outside Air Temp. 0 Transfer from Lsi

AV-104 Mictouch Lever Offset 0 Calculated from current lever position

AV-105 Mictouch Bias Limit 0 Assigned Offset for full stroke

AV-106 Demand Offset 0 Transfer from Lsi
12

Table 2.3. Sample BACnet VAV Box Controller Object Database -Continued

Object Description Default Value Remarks

BV-0 Bad Sensor Alarm OFF

BV-1 Heating/Cooling Mode: On= Heating OFF

BV-2 Persistent Communication Fail OFF

BV-7 Main Air Status - Cold OFF

BV-8 Warm Air in Duct OFF

BV-9 Force Min. Air - Cold OFF

BV-10 Force Reheat Air OFF

BV-11 Force Max. Air - Cold OFF

BV-12 Force Open - Cold OFF

BV-13 Force Closed - Cold OFF

BV-19 Day Mode 2 hour Delay OFF

BV-24 Space Too Warm OFF

BV-25 Space Too Cold OFF

BV-38 Heating Lockout OFF Used for demand control

BV-39 Cooling Lockout OFF Used for demand control

BV-40 Occupied Command OFF Typically sent from Lsi

BV-41 Optimum Start Heating OFF

BV-42 Optimum Start Cooling OFF

BV-64 Occupied SP's Command OFF Turns ON Micset and BV-67

BV-65 OFF Mode Enable OFF OFF button ends daymode

BV-66 Afterhour Timer Status OFF ON when AV-98 > 0, otherwise OFF

BV-67 Occupied Status OFF Determined by BV-64 to BV-66

BV-68 Field Service Lockout OFF ON = Field Service Locked out

BV-69 English/Metric display Swap OFF OFF = Use VLC Mode, ON = Swap

BV-70 Microset Present Flag OFF ON = Microset Present

BV-71 English/Metric VLC Mode OFF OFF = English, Read Only

2.2.3 Data Acquisition System

One of the computers used for the distributed simulation contains an interface card that

communicates digitally with a commercial data acquisition system. This component is called the

"DataLogger" in the system architecture. The simulated values that represent sensor inputs to the

controllers are converted by the digital-to-analog converter of the data acquisition system into

analog outputs represented by either DC voltages (0 V to 5 V) or DC currents (4 ma-20 ma).

There is a capability to scale values to other ranges if needed. The output values of the BACnet

controllers that represent inputs to the virtual building system component models are read by the

digital voltmeter in conjunction with multiplexing scanners of the data acquisition system. Solidstate relay chips are employed for handling binary (digital) signals between a BACnet controller

and the data acquisition system. Figure 2.6 shows the relationship between the data acquisition

system with other components of the VCBT. “Hardwire” represents a pair of electrical wires

used for analog signals. Other connections are digital communication using CORBA. After

receiving data from the computer, converting into the analog values, and sending them to the

controllers, the Datalogger waits 1 s, and then begins to read the controller outputs. The total

cycle time is 3s to 4 s.
13

Figure 2.6. Relationship of the data acquisition system with other units.

2.2.4 Center

The Center controls the flow of data between all other elements of the VCBT. It is also

responsible for starting, initializing, and closing them. Individual components can be selected for

use in a particular run of the VCBT, and the computer that these components will run on can be

chosen at runtime.

The user interface to the center is shown in Figure 2.7 for a typical configuration used for FDD

testing. In this example only the DataLogger, the HVACSIM+

 simulations of the HVAC system

components and the SHELL simulation are active. The status of individual components is shown

in the section marked "A". A green (light) button indicates that the component is active and a red

(dark) button indicates that a component is not being used. The section marked "B" indicates the

tasks for each cycle, with the current task highlighted. The most recent data received by the

center is shown in section "C". The manual controls for initiating components is shown in the

section marked "D."

The Center runs on a 10 s cycle, during which data messages for each active component are

created, transmitted, and any return messages evaluated. Time steps in the HVACSIM+

 and

CFAST simulations are synchronized to correspond to this scan cycle in order to maintain a real-
14

time emulation. The amount of data currently being sent through the Center is only a fraction of

its capability.

Figure 2.7. The Center Interface. In this example only the DataLogger, the HVACSIM+

simulations of the HVAC system components and the SHELL simulation are used.

The Center is responsible for storing every piece of data that is transferred between the various

components of the VCBT. This is done by first creating a list of the objects (i.e. a VAV box or a

room) which have properties (i.e. temperature, humidity, set points) associated with them. The

properties of each object are then created, and linked to their parent object. For each component

of the VCBT, the subset of object and property combinations that the component uses is stored in

a list associated with that component. Separate lists are created for each component for data

going to the component, and for data coming back from the component. The value of any
15

property used in the VCBT can be viewed at the Center. Figure 2.8 illustrates the tree structure

of the Center and the ability to view the value of particular object properties.

Figure 2.8. Data values can be tracked from the Center.

2.2.5 Graphical User Interface

The graphical user interface (GUI) allows for real-time viewing of the VCBT structure through

an interface written in Virtual Reality Modeling Language (VRML). The GUI provides access to

data from the rooms, the VAV boxes, and the AHUs available for the most recent cycle and for

past cycles. This data is presented in the form of graphs and dials. Also, in the event of a fire in

the VCBT, flame size, temperature, smoke density, and the upper smoke layer height are shown

through visual cues.

Figure 2.9 is a GUI display showing a perspective view of one floor of the virtual building. The

image can be rotated, the walls can be made opaque or transparent, and the user can zoom in on

particular rooms or equipment to see more details. Figure 2.10 shows a close-up view of the

AHU serving this floor. This display includes live data from the simulations and animation of the

mechanical equipment. Figure 2.11 is a similar close-up view of one of the VAV boxes.
16

Figure 2.9. Perspective view of one floor of the virtual building.

Figure 2.10. Example AHU in the virtual building showing the visualization of live data.
17

Figure 2.11. Example VAV box in the virtual building showing the visualization of live data.

The GUI consists of three sub-components. The first sub-component of the GUI is called the

Datalink. This sub-component is written in Java. The Datalink receives data from the Center,

reformats the data, and sends the data to the second sub-component, a relational database. The

data is retrieved from the database by the third sub-component, the VRML interface. This

relationship is shown in Figure 2.2. The GUI can be viewed and controlled using any VRMLcapable browser, typically achieved with a VRML plug-in in a conventional WEB browser.

2.2.6 CFAST

One use for the VCBT is to study the impact of unusual events like a fire. The Consolidated

Model of Fire Growth and Smoke Transport (CFAST) model is used to model the behavior of a

virtual fire within the VCBT model building. CFAST uses finite element analysis and a set of

ordinary differential equations that predict the change in enthalpy and mass over time to predict

temperature changes and smoke and gas concentrations. It is a two-zone model, dividing each

room into an upper hot layer and a lower cool layer. Each layer is treated as if it were internally

uniform, but there can be differences in temperature and smoke and gas concentration between

layers. In addition to investigating the impact on building control systems, the ability to create

virtual fires is being used to develop new sensor driven fire models (SDFM) that may eventually

be incorporated into smart fire panels and used to provide predictive information to assist

emergency personnel responding to a fire.
18

3 THE FDD TEST SHELL

3.1 Overview

The FDD Test Shell is a research tool developed to facilitate testing FDD tools (algorithms). It

achieves this goal by separating the task of collecting or generating the process data from the FDD

analysis. By standardizing the method used to access data from specific measurements and

control signals in the server application, FDD client applications can be configured once to

interface to the server application and thereby use the data, regardless of its origin. The Test Shell

can obtain the data from many different sources and present it in real time to one or more FDD

algorithms through a Microsoft Windows dynamic data exchange (DDE) interface. This allows the

researcher to focus on the performance of the FDD algorithm, rather than on the collection or

generation of process data, and would enable side-by-side comparisons of different algorithms.

Any application development environment that supports DDE can create an interface to the Test

Shell.

The FDD Test Shell will be used to interface FDD algorithms to the BACnet controllers in the

VCBT. This laboratory experiment will be used to verify the operation of the Test Shell and the

ability to interface with real BACnet control systems. The FDD Test Shell interface will then be

used for field testing in buildings with BACnet control systems. The field-testing can be done

locally (within the building being monitored), or remotely using BACnet's wide area networking

capabilities using the Internet Protocols (IP). The BACnet capabilities also provide a method for

simultaneously monitoring multiple buildings.

3.2 Architecture

Figure 3.1 illustrates the architecture of the FDD Test Shell. Sections 3.2.1-3.2.3 will discuss the

role of each component along with the implementation. In this approach, the modular

architecture provides a structured way to share data, models and methods. The Windows DDE

platform was chosen because it is commonly available and it allows shared FDD resources to be

developed in a variety of application development environments. This includes C++, MATLAB2

,

Basic, and spreadsheet programs.

 

2

 Use of product names does not imply recommendation of any commercial products by the National Institute of

Standards and Technology.
19

Coordinator 

(with graphical display templates)

FDD Tool

#1

FDD Tool

#2

FDD Tool

#3

Design

Experiment

Model

Residual Design

Residual

Σ Σ

Data Source

(File, BACnet)

 Reference

Model

- - + +

Figure 3.1. FDD Test Shell Architecture.

3.2.1 The Coordinator Program

At the heart of the Test Shell is a DDE server program called the Coordinator. The Coordinator

consists of data tables and graphical templates used for displaying data of specific types of

equipment. The Coordinator tables, made up of the Design, Design Residual, Experiment,

Model, and Residual tables, and the information they contain, are described below.

The Coordinator responds to DDE Advise loops. When an advise loop is requested for a

particular Topic/Item, the Coordinator will advise the client program when the cell’s time value

changes. In the case of both the Design table and the Experiment table, updates come directly

from the Data Source program (discussed in section 3.2.2). In the Design table, the coordinator

pokes all the available design data values for the building (e.g., system parameters) and provides

this data to the FDD tools as requested. In the experiment table, the coordinator pokes contains

the complete time series operational data.

The Model table holds predicted values (usually representing normal performance). As the

Experiment table is modified, the Coordinator advises the Reference Model program which in

turn updates its calculations. When new output reference data is available, the coordinator pokes

it into the Model table. However, it is important to note that the Coordinator’s Experiment table

may be used independently of the Reference Model. For instance, if the implementation of an

FDD method has embedded models or does not utilize models of reference operation, raw data

can be requested directly from the Experiment table.

As new data streams into the Experiment table and Design table, a series of calculations are

automatically made to obtain desired residual values. Specifically, the Residual table reflects the
20

difference between values in the Experiment and Model tables, and the Design Residual table

reflects the difference between values in the Experiment and Design tables.

The Coordinator currently includes graphical templates for air-handling units (AHUs) and vapor

compression cycles. As time series data streams through the Coordinator, the appropriate graphic

is updated to reflect the current values of the available data. The FDD programs can request data

from any of the Coordinator’s tables or be advised when new data are available. They operate on

the data and present results on independent user interfaces. The standard data contained in the

templates are described in Section 3.4.

3.2.2 Data Source Program

The Data Source program pokes time series data into the Coordinator. Several different sources

can be used as Data Source, including:

• stored trend data files from a building automation system or other source (simulation,

laboratory, etc.) (File Data Source),

• stored data from a computer simulation (which may be poked to the Coordinator faster than

real-time) (File Data Source),

• real-time data made available by software controlling a laboratory test rig or a building

control system (File Data Source), or

• real-time data from BACnet controllers (BACnet Data Source)

The data poked to the Coordinator are time stamped which allows the programs to identify when

new data are available. Additionally, the File Data Source program has a utility that allows it to

present data from trend files to the Coordinator in faster than real time. To simplify the process of

sharing and using data files produced by different individual programs, a data set standard was

developed that specifies formatting requirements for the File Data Source program or BACnet Data

Source program. The data set standard is provided in section 3.3.

Using the BACnet Data Source program, the FDD Test Shell is used to interface FDD algorithms

to the BACnet controllers in the VCBT. BACnet ReadProperty service requests are generated at

timed intervals (the default being 10 s) to collect the necessary data from the controllers. The

data are poked into the Coordinator’s Experiment table for a complete scan cycle that ends with a

change to the time stamp cell. The time stamp can be represented in a variety of formats. A

mapping feature defines which BACnet property values are inserted into specified Coordinator

cells. The program allows for a variety of transformations of data from the input source to the

representation needed by the FDD method. The BACnet Data Source program also pokes the

design data into the Design table which is in turn accessed by the FDD methods. Most of the

operational data is read directly from the controllers, but in the case of design data, a

configuration file is used.

3.2.3 Using Reference Models with the Coordinator

The FDD Test Shell allows testing both self-contained FDD methods and FDD methods that

require or can use a supporting reference model. Reference models, if used, react to advisories

from the Coordinator that new data are available in the Experiment Table. They request input

values from the Experiment table, calculate reference or baseline output values, and poke them
21

both into the Model table. The Coordinator calculates the difference between the Experiment and

Model tables and inserts the results in the Model Residual table.

This feature facilitates the comparison of different FDD methods using the same reference

model. This provides a means of separating the effect of reference models and FDD methods

when assessing overall performance.

3.3 Data Standard

To simplify the effort necessary to share data files among Test Shell users, a data set standard

was established. The File Data Source program was designed to read data from files that conform

to the standard. The following rules define the standard:

1. All the measurements are included in ASCII data files. Each line in the file contains data

sampled at different times.

2. The first entry in each line is the time stamp. Several standards are accepted:

• MM/DD/YY HH:MM:SS.SSSSSS

• DD.MM.YY HH:MM:SS

• YYMMDD HHMM

• Seconds

3. The measurements follow the time stamp on each line and are delimited by any valid ASCII

character not found in the ASCII representation of floating point numbers (e.g. “,” delimiter

makes a comma separated value (.csv) file easily interpreted by Microsoft Excel).

4. The design value for each measurement is included in the first row of the file.

5. Lines starting with the ASCII character “*” designate comment lines.

6. The ASCII string “NaN” is used in place of measurements when no valid numbers are

available (e.g. measured value outside of sensor range).

3.4 AHU Template

The Coordinator program is comprised of data cells containing measurements, control signals,

set points, etc. at a specified time. To standardise data transfer, an AHU template was established

to specify the measurements and units associated with each cell (see Table 3.1). The software

implementations of the template include a graphic that displays the time series data in the

appropriate physical location. For trend files, the File Data Source program provides a utility for

mapping file columns to cells, converting units, and setting default cell values for data not

included in the file. A File Data Source configuration file that maps file contents to the

appropriate standard template accompanies all standard data files associated with the FDD Test

Shell software.
22

Table 3.1. Air Handling Unit DDE Template.

Cell Measurement Units

1 Time HH :MM :SS

2 Occupancy 0/1 for unoccupied/occupied

3 Supply Air Setpoint Temperature C

4 Supply Air Temperature C

5 Return Air Temperature C

6 Mixed Air Temperature C

7 Outdoor Air Temperature C

8 Cooling Coil Inlet Temperature C

9 Heating Coil Inlet Temperature C

10 Cooling Coil Discharge Temperature C

11 Heating Coil Discharge Temperature C

12 Chilled Water Supply Temperature C

13 Hot Water Supply Temperature C

14 Supply Air Relative Humidity 0 % to 100 %

15 Return Air Relative Humidity 0 % to 100 %

16 Outdoor Air Relative Humidity 0 % to 100 %

17 Cooling Coil Inlet Relative Humidity 0 % to 100 %

18 Cooling Coil Discharge Relative Humidity 0 % to 100 %

19 Supply Air Flow Rate m3/s

20 Return Air Flow Rate m3/s

21 Exhaust Air Flow Rate m3/s

22 Outdoor Air Flow Rate m3/s

23 Chilled Water Flow Rate (through coil) m3/s

24 Hot Water Flow Rate (through coil) m3/s

25 Return Fan Power kW

26 Supply Air Pressure Setpoint Pa

27 Supply Air Pressure Pa

28 Cooling Coil Valve Control Signal 0 % to 100 %

29 Heating Coil Valve Control Signal 0 % to 100 %

30 Mixing Box Damper Control Signal 0 % to 100 %

31 Supply Fan Control Signal 0 % to 100 %

32 Return Fan Control Signal 0 % to 100 %

33 Supply Fan Power kW

34-43 Room Air Relative Humidity 0 % to 100 %

44-60 Room Air Temperature C

3.5 Interfacing to the Coordinator

The only requirement for interfacing to the coordinator is that the application must be compatible

with the Dynamic Data Exchange (DDE) communications protocol. Data Source programs

control the collection of data and the flow of data to the Coordinator. The Data Source program

intially connects to the Design Table and the Experiment Table of the Coordinator. The Design

Table is filled with initial values. The Experiment Table is refilled with data at every time step.
23

The Experiment Table is filled with data in a two step process. In the first step, all of the data for

cells 2-53 are collected and sent to the coordinator via a Poke with the handle string set to ‘all’.

The data is formatted as a single text string with the values delimited by spaces. In the second

step, the time is sent to the coordinator via a Poke with the handle string set to ‘1’. The time data

is formatted as a text string containing the number of seconds past midnight for the current

timestep. When the date in cell 1 of the Experiment Table is updated, it will trigger an Advise

loop which will trigger the FDD methods, telling them that there is new data available. If a

Reference Model program is being used, it will also be triggered. The Reference Model program

will then update the Model Table and the Residual Tables.

4 FAULT MODELS

This section describes the faults and fault models implemented in the HVACSIM+

 simulation

model introduced in section 2. The systems considered are a single duct variable-air-volume

(VAV) air-handling unit (AHU) and a single duct VAV box with reheat. Typical sequences of

operation and normal operating conditions are described for the systems. The faults considered

are then described and the expected impacts of the faults are discussed. Open-loop tests designed

to quantify the thermal impact of leakage faults for AHU valves and dampers are also discussed.

It is not practical or even possible to address all the AHU and VAV box systems and the

associated sequences of operation and faults that might be encountered in real buildings. The

systems described in this chapter are representative of real building applications and are an

appropriate starting point for testing and demonstrating FDD tools.

4.1 Air Handling Units

4.1.1 Normal Operation

Figure 4.1 is a schematic diagram of a typical single duct VAV AHU. The AHU consists of

variable speed supply and return fans, three dampers for controlling airflow to and from the

AHU to the outdoor environment, hydronic heating and cooling coils for conditioning the air,

various sensors and actuators, and a controller that receives sensor measurements and computes

and transmits new control signals. The operation of the AHU is quite straightforward

conceptually. Outdoor air enters the AHU and is mixed with air returned from the building. The

mixed air passes over the heating and cooling coils, where if necessary, it is conditioned prior to

being supplied to the building. While seemingly straightforward, there are a number of

interdependent control loops that dictate system operation. These control loops are summarized

in the ensuing discussion. The descriptions of the control loops focus on the strategies

implemented in the VCBT; however, in certain cases other common control strategies are also

described to make the discussion more general.
24

T & H

Return

Fan

Supply

Fan

M

M

M

M

Heating

Coil

Cooling

Coil

Air Handling Controller

OUTPUTS

INPUTS

T & H

T

T

Exhaust Air

Damper N.C.

Recirculation

 Air Damper N.O.

Mixed

Air

Supply

Air

Return Air Temperature

and Humidity Sensors

Filter

To

Zones 

From

Zones 

Outdoor Air

Damper N.C.

Cooling Coil Heating Coil Valve N.C.

Valve N.O.

Outdoor

Air

M

Figure 4.1. Schematic diagram of a single duct air-handling unit.

The supply fan of a VAV AHU is controlled to maintain the static pressure in the supply duct,

typically at a constant setpoint value. To accomplish this, the static pressure and its setpoint

value are input to a feedback control loop (typically a proportional-integral control algorithm).

The output of the control loop is a signal that is used to control a variable speed drive for the fan.

Supply air is distributed to various zones (not shown), which may have different loads and

setpoint temperatures. To account for the variability of the conditions in the zones, VAV boxes

(not shown) that regulate the amount of air that enters a zone are placed at the end of the supply

air ductwork leading to each zone. As a zone load decreases, the corresponding VAV box

restricts the flow of air to the zone, thereby increasing the static pressure in the supply duct and

causing the supply fan speed to decrease in order to maintain the static pressure setpoint

condition. If the zone load increases, the VAV box and supply fan respond in the opposite

manner.

The return fan is typically controlled to maintain zone pressurization. There are several ways this

can be achieved. With the volume matching control strategy employed here, the return fan is

controlled to maintain a constant differential between the supply and return airflow rates so that
25

the zones have a small positive pressurization, thus reducing infiltration. Airflow stations (not

shown in Figure 4.1) are used to measure the airflow rates in the supply and return air ducts.

AHUs are typically controlled to maintain the supply air temperature at a setpoint value at a

location in the supply duct downstream of the supply fan. There are four primary modes of

operation used during occupied periods to accomplish this task. Sequencing logic determines the

mode of operation of an AHU at any particular time. Figure 4.2 shows a state transition diagram

for a finite state machine sequencing control strategy for AHUs (figure taken with author’s

permission from Seem et al. 1999 [12]). The state transition diagram illustrates the modes of

operation and the logic used to transition between modes of operation during occupied times (the

terms mode and state are used interchangeably here). Seem et al. (1999) also describe a splitrange sequencing control strategy that uses the output of a single control loop to operate the

dampers, heating valve and cooling valve in sequence to achieve the desired supply air

temperature set point. The purpose and effect of the finite state machine strategy and the splitrange strategy are essentially the same, although their implementations differ greatly. The finite

state machine logic depicted in Figure 4.2 will be used in this discussion to help illustrate the

normal operation of AHUs.

In the heating mode (State 1 in Figure 4.2), the heating coil valve is controlled to maintain the

supply air temperature at the set point and the cooling coil valve is closed. The outdoor air

dampers are positioned to allow the minimum outdoor air necessary to satisfy ventilation

requirements. As cooling loads increase, the AHU transitions from heating to cooling with

outdoor air (State 2). In this mode, the heating and cooling coil valves are closed and the mixing

box dampers are modulated to maintain the supply air temperature set point. As the loads

continue to increase, the mixing dampers eventually saturate with the outdoor air dampers fully

open and the AHU changes modes again to mechanical cooling. When the AHU is operating in

the mechanical cooling mode, the cooling coil valve modulates to maintain the supply air

temperature set point, the heating coil valve is closed, and the outdoor air dampers are either

fully open (State 3) or at the minimum ventilation position (State 4) as determined by

economizer logic. Economizer control logic often uses a comparison of the outdoor and return

air temperatures or enthalpies to determine the proper position of the outdoor air dampers such

that mechanical cooling requirements are minimized. For the enthalpy-based economizer used

here, the outdoor air dampers are fully open if the return air enthalpy is greater than the outdoor

air enthalpy. If the return air enthalpy is less than the outdoor air enthalpy, the outdoor air

dampers are positioned for minimum outdoor air.

In many AHU control systems, the supply air setpoint temperature is maintained at a constant

value for the sake of simplicity. Reset strategies are also commonly used. The AHU controllers

used here have a reset strategy that adjusts the supply air setpoint temperature to satisfy the

maximum cooling demand required in any one of the zones during the cooling season. Other

reset strategies are based on the return air temperature or outdoor air temperature, with the

supply air setpoint temperature being lowered as these temperatures increase.
26

State 1 (Mode 1)

Feedback Control of Heating Coil

(Minimum Outdoor Air & No Mechanical Cooling)

State 2 (Mode 2)

Feedback Control of Dampers

(No Heating & No Mechanical Cooling)

State 3 (Mode 3)

Feedback Control of Cooling Coil

(Maximum Outdoor Air & No Heating)

State 4 (Mode 4)

Feedback Control of Cooling Coil

(Minimum Outdoor Air & No Heating)

Control Signal for Heating Coil

Saturated in No Heating Position

Control Signal for Dampers Saturated

In Maximum Outdoor Air Position

Outdoor Air Enthalpy > Return Air

Enthalpy + Deadband Enthalpy

Outdoor Air Enthalpy < Return Air

Enthalpy - Deadband Enthalpy

Control Signal for Cooling Coil

Saturated in No Cooling Position

Control Signal for Dampers Saturated

In Minimum Outdoor Air Position

State 1 (Mode 1)

Feedback Control of Heating Coil

(Minimum Outdoor Air & No Mechanical Cooling)

State 2 (Mode 2)

Feedback Control of Dampers

(No Heating & No Mechanical Cooling)

State 3 (Mode 3)

Feedback Control of Cooling Coil

(Maximum Outdoor Air & No Heating)

State 4 (Mode 4)

Feedback Control of Cooling Coil

(Minimum Outdoor Air & No Heating)

Control Signal for Heating Coil

Saturated in No Heating Position

Control Signal for Dampers Saturated

In Maximum Outdoor Air Position

Outdoor Air Enthalpy > Return Air

Enthalpy + Deadband Enthalpy

Outdoor Air Enthalpy < Return Air

Enthalpy - Deadband Enthalpy

Control Signal for Cooling Coil

Saturated in No Cooling Position

Control Signal for Dampers Saturated

In Minimum Outdoor Air Position

Figure 4.2. Sequencing control strategy for controlling air-handling units (adapted

from Seem et al. 1999).

4.1.2 AHU Faults: Implementation and Expected Impact

The faults that have been implemented in the HVACSIM+

 code have a thermal impact on the

AHU. The faults considered are 1) supply air temperature sensor offset, 2) return air temperature

sensor offset, 3) mixed air temperature sensor offset, 4) outdoor air temperature sensor offset, 5)

stuck/leaking outdoor air damper (both stuck and leaking faults are simulated, although not

simultaneously), 6) stuck/leaking recirculation air damper, 7) stuck/leaking cooling coil valve,

and 8) stuck/leaking heating coil valve. These faults are representative of the most commonly

occurring faults in AHUs [11

Supply Air Temperature Sensor Offset

• Fault Condition: 0 oC to –4 oC

0 oC to +4 oC

• HVACSIM+

 TYPE 301: Temperature sensor

• HVACSIM+

 Unit: Supply air temperature sensor

• HVACSIM+

 Variable: Offset (input for zero output)

The fault (and all temperature sensor faults considered in this chapter) is introduced by linearly

increasing or decreasing the temperature sensor model offset parameter (parameter 1) as time

increases. The initial offset is 0 oC, increasing to ±4 oC over a two week period.
27

A positive offset will produce an artificially low sensor reading. That is, if the actual supply air

temperature is 15 oC and a +4 oC offset is imposed via parameter 1 of the model, the sensed

temperature will be 11 oC. The controller wants to maintain the supply air temperature at the set

point and will respond accordingly. When cooling is required, this fault will lead to warmer

supply air temperatures than anticipated and may also affect the supply air humidity. To

compensate for the higher supply temperature, the VAV boxes will open further, leading to

increased fan energy use. Conversely, the fault may reduce chiller energy use and may also

reduce reheat energy use. Occupant comfort could be sacrificed by higher supply air temperature

and humidity levels. In the heating mode it is anticipated that the fault will lead to additional

boiler energy use as the heating coil valve must open further to meet the set point.

A negative offset will produce an artificially high sensor reading. This fault will lead to cooler

supply air temperatures than anticipated. To compensate for the lower supply temperature, the

VAV boxes will close to some degree, leading to reduced fan energy use. The chiller energy use,

on the other hand, will increase and in some cases, reheat energy may be needed to offset the

lower supply air temperature. In the heating mode it is anticipated that the fault will lead to

reduced boiler energy use. However, reheat energy use may increase to compensate for lower

supply air temperatures.

Return Air Temperature Sensor Offset

• Fault Condition: 0 oC to –4 oC

0 oC to +4 oC

• HVACSIM+

 TYPE 301: Temperature sensor

• HVACSIM+ Unit: Return air temperature sensor

• HVACSIM+

 Variable: Offset (input for zero output)

The fault is introduced as described for the supply air temperature sensor fault. The return air

temperature sensor is not universally used for control purposes in AHUs. If it is used, it is used in

the economizer logic to determine when to switch from 100 % outdoor air to minimum outdoor

air. In the simplest case of a dry-bulb economizer, the return air temperature is compared with

the outdoor air temperature. If the return air temperature is the higher of the two readings, the

unit will operate with the dampers positioned for 100 % outdoor air. If the return air temperature

reading is artificially high, 100 % outdoor air will be used under certain conditions where it

would be advantageous from an energy standpoint to use minimum outdoor air. If the return air

temperature is artificially low, the opposite effect will occur. Minimum outdoor air will be used

under certain circumstances when it would be advantageous to use 100 % outdoor air. In either

case there is an energy penalty, with the severity of the penalty depending on the offset.

Mixed Air Temperature Sensor Offset

• Fault Condition: 0 oC to –4 oC

0 oC to +4 oC

• HVACSIM+

 TYPE 301: Temperature sensor

• HVACSIM+ Unit: Mixed air temperature sensor

• HVACSIM+ Variable: Offset (input for zero output)
28

The fault is introduced as described for the supply air temperature sensor fault. In many systems,

the mixed air temperature sensor is not used for control purposes. In these systems, the sensor

error will not impact the unit operation. The only impact of the fault would be to reduce its

effectiveness as a diagnostic sensor. For instance, if the mixing box damper control signals

indicate a call for 100 % outdoor air, the mixed air temperature and outdoor air temperature can

be compared to verify proper operation of the dampers. If cooling is achieved using outdoor air

(no mechanical cooling), the mixed air temperature and supply air temperature can be compared

to verify that the heating and cooling valves are not open or leaking. Of course in the latter case,

the temperature rise across the supply fan must be accounted for.

In some systems, a separate control loop may be used to modulate the mixing box dampers to

maintain the mixed air temperature at a set point. In such systems, sensor offset may lead to

severe energy penalties. For instance, if the mixed air sensor is reading artificially high, the AHU

may have to compensate by heating the air using the heating coil. A similar effect would be seen

if the sensor is reading artificially low. In this case it might be necessary to compensate by

cooling the air using the cooling coil. The AHU model considered in this study does not include

a separate mixed air temperature controller. Nonetheless, these examples are raised to reinforce

the importance of this particular fault.

Outdoor Air Temperature Sensor Offset

• Fault Condition: 0 oC to –4 oC

• 0 oC to +4 oC

• HVACSIM+

 TYPE 301: Temperature sensor

• HVACSIM+

 Unit: Outdoor air temperature sensor

• HVACSIM+ Variable: Offset (input for zero output)

The fault is introduced as described for the supply air temperature sensor fault. The impact of

this fault is the opposite of the impact described for the return air temperature sensor. If the

outdoor air temperature reading is artificially high, economizer logic will cause the AHU to

transition to the minimum outdoor air mode for conditions where operation with 100 % outdoor

air is appropriate. If the outdoor air temperature reading is artificially low, the AHU will

transition to 100 % outdoor air for conditions where operation with minimum outdoor air is

appropriate.

Another impact of this fault would be seen in AHUs that use a reset strategy based on outdoor air

temperature to adjust the supply air temperature set point. If the outdoor air temperature sensor

reading is artificially high, the supply air set point will tend to be set too low, causing an energy

penalty due to excessive chiller use and, perhaps, reheat energy use. The simulation model uses a

reset schedule; however, it is not based on a direct measurement of the outdoor air temperature.
29

Stuck Outdoor Air Damper

• Fault Condition: Stuck open, closed, or at its minimum position

• HVACSIM+

 TYPE 321: Motor-driven actuator

• HVACSIM+ Unit: Outdoor air damper actuator

• HVACSIM+ Variable: Position of final control element (0 for stuck closed and 1 for stuck

open)

During normal operation, the outdoor air damper modulates when the conditions are right for

cooling with outdoor air (State 2), is fully open when the AHU calls for 100 % outdoor air (State

3), and is at its minimum position otherwise. The relationships between the positions of the

mixing box dampers under normal operating conditions are shown in Figure 4.3 versus the

commanded recirculation air damper position. For these tests, the minimum outdoor air position

is 40 % open. The commanded damper position corresponds to the output signal to the damper

and may be different from the actual position due to the presence of a fault, hysteresis effects,

etc.

Commanded Recirculation

Air Damper Position (% Closed)

0 100

Recirculation

Air Damper

Damper Position (% Open)

0

100

Outdoor

Air Damper

Exhaust

Air Damper

100

0

Minimum

Position

Commanded Recirculation

Air Damper Position (% Closed)

0 100

Recirculation

Air Damper

Damper Position (% Open)

0

100

Outdoor

Air Damper

Exhaust

Air Damper

100

0

Minimum

Position

Figure 4.3. AHU mixing box damper position relationships.
30

Recirculation Air Damper Position (% Closed)

0 20 40 60 80 100

Percentage Outdoor Air (%)

0

20

40

60

80

100

normal

closed

minimum

open

Outdoor Air Damper

Figure 4.4. Outdoor air percentage versus recirculation air damper

position with the outdoor air damper operating normally, stuck

closed, stuck at the minimum position, and stuck open.

To consider the impact of a stuck outdoor air damper requires that several cases be examined.

Figure 4.4 shows the percentage of outdoor air (mass flow rate of outdoor air divided mass flow

rate of supply air multiplied by 100) versus recirculation air damper position for a case where the

outdoor air damper operates normally, and for cases where the outdoor air damper is stuck

closed, stuck at its minimum position, and stuck 100 % open. For the most part the outdoor air

percentage is nearly the same for the fault cases and normal operation. The clear exception is the

case where the outdoor air damper is stuck closed. Note the high percentage of outdoor air

(approximately 63 %) corresponding to a stuck closed outdoor air damper and a 100 % closed

recirculation damper. The large percentage of outdoor air is indicative of a substantial decrease

in the supply airflow rate for this case, not of a large increase in the outdoor airflow rate.

Because the supply air must be drawn through one of two closed dampers, the supply airflow

rate is only 2.2 m3

/s, which is approximately 79 % less airflow than when the recirculation air

damper is 0 % to 33 % closed. Hence, when both dampers are closed, the power drawn by the

supply fan will decrease considerably due to the decrease in flow delivered by the fan. The

supply static pressure will also decrease because there would likely be an extreme negative

pressure at the intake to the supply fan.

A less significant fault impact is observed when the outdoor air damper is stuck at its minimum

position. The results seem to indicate that furthering testing of the case where the outdoor air

damper is stuck open is not warranted because the fault has no observable symptoms. While this

conclusion is true for the existing system configuration and control strategy while the AHU is

running, stuck open outdoor air damper faults should not be ignored in general. In cold weather,

the fault could lead to frozen coils under a number of scenarios. For instance, systems lacking a

return fan as well as those designed with a supply and exhaust fan configuration would be

susceptible to this fault. The fault could also create the potential for freezing coils when the AHU

is not running, regardless of whether the AHU includes a return fan or not.
31

Leaking Outdoor Air Damper

• Fault Condition: 10 %, 25 %, 40 % of full flow

• HVACSIM+

 TYPE 327: AHU mixing box with minimum outdoor damper (minimum

damper disabled)

• HVACSIM+

 Unit: AHU mixing box

• HVACSIM+ Variable: Leakage for outdoor air damper (0 to 1: fraction of full flow)

This fault was implemented by changing the leakage parameter for the modulating outdoor air

damper from its normal value of 0.01 to 0.1, 0.25, and 0.4. The fault is expected to produce

increasing values of the fraction of outdoor air when the outdoor air damper is 100 % closed and

the recirculation damper is 100 % open. In a normally operating AHU, the outdoor air damper

would likely be closed during a morning warm-up cycle, but rarely otherwise. The simulation

model used in this study does not include a morning warm-up cycle. Hence, simulations of

leaking outdoor air dampers will not reveal symptoms that can be used by a diagnostic tool.

Stuck Recirculation Air Damper

• Fault Condition: Stuck open or closed

• HVACSIM+ TYPE 321: Motor-driven actuator

• HVACSIM+ Unit: Recirculation air damper actuator

• HVACSIM+

 Variable: Position of final control element (0 for stuck closed and 1 for stuck

open)

This fault is expected to have a significant impact on the outdoor air fraction. If the recirculation

damper is stuck open, the fraction of outdoor air will be less than normal when the mixing box

dampers are modulating and when the outdoor air damper is 100 % open. This will create an

energy penalty, particularly when it is economically advantageous to use 100 % outdoor air. If

the recirculation damper is stuck closed, the fraction of outdoor air will be nearly equal to unity

at all times because the outdoor air damper will be open to at least its minimum position and the

supply fan will draw air through this path. Figure 4.5 shows the percentage of outdoor air versus

the commanded recirculation air damper position when the recirculation damper is operating

normally, stuck closed, and stuck open. When considering the data in Figure 4.5, it is important

to remember the damper position relationships depicted in Figure 4.3. In particular, a

commanded recirculation damper position of 0 % closed corresponds to an outdoor air damper

position of 40 % open. Hence, the 83 % outdoor air percentage for this situation is not

unreasonable.

Leaking Recirculation Air Damper

• Fault Condition: 10 %, 25 %, 40 % of full flow

• HVACSIM+

 TYPE 327: AHU mixing box with minimum outdoor damper (minimum

damper disabled)

• HVACSIM+ Unit: AHU mixing box

• HVACSIM+

 Variable: Leakage for recirculation air damper (0 to 1: fraction of full flow)
32

This fault was implemented by changing the leakage parameter for the recirculation air damper

from its normal value of 0.01 to 0.1, 0.25, and 0.4. The fault is expected to reduce the outdoor air

fraction when the modulating outdoor air damper is 100 % open (at this condition, the outdoor

air fraction should be nearly equal to unity). This will create an energy penalty during those

times when it is advantageous to use 100 % outdoor air. The thermal impact (i.e., how do the

changing airflow rates impact the mixed air temperature) of this fault is examined in section

4.1.3.

Stuck Cooling Coil Valve

• Fault Condition: Stuck closed

• HVACSIM+

 TYPE 321: Motor-driven actuator

• HVACSIM+

 Unit: Cooling coil valve actuator

• HVACSIM+ Variable: Position of final control element (0 for stuck closed)

Commanded Recirculation Air Damper Position (% Closed)

0 20 40 60 80 100

Percentage Outdoor Air (%)

0

20

40

60

80

100

normal 

closed 

open 

Recirculation

Air Damper

Figure 4.5. Outdoor air percentage versus commanded recirculation

air damper position with the recirculation damper operating normally,

stuck closed, and stuck open.

A stuck closed cooling coil valve fault is implemented by setting the first output variable for the

valve actuator equal to zero. This fault will manifest itself in the inability of the AHU to maintain

the supply air temperature at the set point in the mechanical cooling modes. Comfort will be

sacrificed due to the fault, but energy use may decrease because the air is not being cooled.
33

Leaking Cooling Coil Valve

• Fault Condition: 10 %, 25 %, 40 % of full flow

• HVACSIM+

 TYPE:524: Coil plus three port valve

• HVACSIM+ Unit: Cooling coil plus three port valve

• HVACSIM+ Variable: Valve leakage (0 to 1: fraction of full flow)

A leaking cooling coil valve fault is implemented by changing the leakage parameter for the

valve from its normal value of 0.1e-3 to 0.1, 0.25, and 0.4. The fault is modeled such that its

primary impact occurs when the valve is closed. The fault is expected to produce an energy

penalty during the heating mode and the cooling with outdoor air mode. In the heating mode the

energy penalty takes the form of unnecessary mechanical cooling and extra heating that is

required to offset the cooling. In the cooling with outdoor air mode, the energy penalty is due to

unnecessary mechanical cooling. It should also be pointed out that the fault forces the AHU to

operate in the heating mode under certain conditions that would normally enable the AHU to

operate in the cooling with outdoor air mode. The thermal impact (i.e., what is the temperature

drop across the cooling coil associated with the leakage) of this fault is examined in section

4.1.3.

Stuck Heating Coil Valve

• Fault Condition: Stuck closed

• HVACSIM+ TYPE 321: Motor-driven actuator

• HVACSIM+ Unit: Heating coil valve actuator

• HVACSIM+

 Variable: Position of final control element (0 for stuck closed)

A stuck closed heating coil valve fault is implemented by setting the first output variable for the

valve actuator equal to zero. This fault will manifest itself in the inability of the AHU to maintain

the supply air temperature at the set point in the heating mode. The absence of heating in the

central AHU will be offset by the capability to reheat the air in the VAV boxes. It is unclear what

the temperature and comfort implications of this fault will be.

Leaking Heating Coil Valve

• Fault Condition: 10 %, 25 %, 40 % of full flow

• HVACSIM+

 TYPE:524: Coil plus three port valve

• HVACSIM+ Unit: Heating coil plus three port valve

• HVACSIM+ Variable: Valve leakage (0 to 1: fraction of full flow)

A leaking heating coil valve fault is implemented by changing the leakage parameter for the

valve from its normal value of 0.1e-3 to 0.1, 0.25, and 0.4. The fault is modeled such that the

primary impact occurs when the valve is closed. The fault is expected to produce an energy

penalty during all modes of operation except the heating mode. In the cooling with outdoor air

mode, the energy penalty is due to unnecessary heating. In the mechanical cooling modes, not

only does unnecessary heating occur, but additional cooling is also required to offset the load

imposed by the heating coil. The thermal impact (i.e., what is the temperature rise across the

heating coil associated with the leakage) of this fault is examined in section 4.1.3.
34

4.1.3 Open-Loop Tests of Select Faults

Evaluating the performance of FDD tools is achieved more readily when the impacts of the

considered faults are quantified in a common manner. The temperature sensor faults described in

the previous section are all quantified by the temperature offset associated with the fault. In this

section, the leakage faults of the recirculation air damper, the cooling valve and the heating valve

will be quantified based on the thermal impact of the respective faults. For instance, the impact

of a 10% leakage fault for the heating coil valve will be quantified in terms of the temperature

rise across the coil. Quantification of the faults will be done by establishing open-loop control

modes with fixed inlet conditions.

The previous section described how the primary impact of leakage through the outdoor air

dampers is observed during morning warm-up and further pointed out that this mode of operation

is not included in the simulation model considered here. Hence, the thermal impact of this fault is

not described below.

Leaking Recirculation Air Damper

Leakage through the recirculation air damper is of concern when the AHU operates in the

mechanical cooling with 100 % outdoor air mode. In this case, the recirculation damper is

closed, while the outdoor and exhaust air dampers are fully open. The fixed open-loop conditions

imposed on the AHU are summarized below:

• Recirculation Air Damper: closed

• Outdoor Air Damper: fully open

• Exhaust Air Damper: fully open

• Supply Fan Speed: 100 %

• VAV Boxes: 100 % open

• Return Air Temperature: 21.11 oC (upstream of the return fan)

• Return Air Humidity Ratio: 0.0078 kg vapor/kg air(upstream of the return fan; at 21.11 oC,

this humidity ratio corresponds to 50 % relative humidity)

Open-loop tests were performed for outdoor air temperatures of 10 oC, 15 oC, and 20 oC. The

humidity ratio of the outdoor air was adjusted in each case to achieve 50 % relative humidity.

For each outdoor air temperature, tests were performed with return fan speeds of 80 %, 60 %, 40

% and 20 %, which imposed different pressure conditions on the recirculation damper. The

results are quantified in terms of the temperature difference between the mixed air and the

outdoor air for different leakage values and are shown in Figures 4.6 for a return fan speed of

80%. For no leakage (or more correctly stated, the nominal leakage associated with the fault free

model), this temperature difference should be nearly equal to zero. This is borne out by the

results. Clearly, the greater the temperature difference between the return air and the outdoor air,

the greater the
35

Leakage (% )

0 5 10 15 20 25 30 35 40

M ixed AirTem perature 

-

OutdoorAirTem perature (

oC)

0

1

2

3

4

5

Toa = 10oC

Toa = 15oC 

Toa = 20oC

Figure 4.6. Thermal impact of recirculation damper leakage for outdoor

air temperatures of 10 oC, 1 5oC and 20 oC.

impact of the leakage fault. It should be noted that the leakage proved to be essentially

insensitive to the return fan speed.

Leaking Cooling Coil Valve

Leakage through the cooling coil valve is of concern when the AHU operates in the heating

mode and the cooling with outdoor air mode. In these modes, the inlet air temperature to the

cooling coil would be expected to be in the range of 15 oC to 20 oC. Lower temperatures might

be encountered; however, because the chilled water inlet temperature is 6 oC, the impact of a

leakage fault at lower temperatures should be minor. The fixed open-loop conditions imposed on

the AHU are summarized below:

• Recirculation Air Damper: closed

• Outdoor Air Damper: fully open

• Exhaust Air Damper: fully open

• Supply Fan Speed: 100 %

• Return Fan Speed: 90 %

• VAV Boxes: 100 % open

• Chilled Water Inlet Temperature: 6oC

Open-loop tests were performed for inlet air temperatures to the cooling coil of 15 oC and 20 oC.

The humidity ratio of the inlet air was adjusted for the two cases to achieve 50 % relative

humidity. The results are quantified in terms of the temperature drop across the cooling coil at

different leakage rates and are shown in Figure 4.7. The impact of the leakage faults will be more

significant when the supply fan speed is lower.
36

Leakage (% )

0 10 20 30 40 50 60

Tem perature D rop A cross Coilo

(C)

0

1

2

3

4

5

6

Toa = 15oC 

Toa = 20oC

Figure 4.7. Thermal impact of cooling coil valve leakage for

inlet air temperatures to the coil of 15 oC and 20 oC.

Leaking Heating Coil Valve

Leakage through the heating coil valve is of concern when the AHU operates in the mechanical

cooling modes and in the cooling with outdoor air mode. In these modes, the inlet air

temperature to the heating coil would be expected to be in the range of 15 oC to 30 oC. The

higher temperatures would likely be encountered only in applications with high percentages of

outdoor air. The fixed open-loop conditions imposed on the AHU are summarized below:

• Recirculation Air Damper: closed

• Outdoor Air Damper: fully open

• Exhaust Air Damper: fully open

• Supply Fan Speed: 100 %

• Return Fan Speed: 90 %

• VAV Boxes: 100 % open

• Hot Water Inlet Temperature: 60 oC

Open-loop tests were performed for inlet air temperatures to the heating coil of 15 oC, 20 oC, 25

oC, and 30 oC. The humidity ratio of the inlet air was adjusted for each case to achieve 50 %

relative humidity. The results are quantified in terms of the temperature rise across the heating

coil at different leakage rates and are shown in Figure 4.8. The impact of the leakage faults will

be more significant when the supply fan speed is lower.
37

Leakage (% )

0 10 20 30 40 50 60

Tem perature Rise A cross Coilo

(C)

0

1

2

3

4

5

6

7

Toa = 15oC 

Toa = 20oC 

Toa = 25oC 

Toa = 30oC 

Figure 4.8. Thermal impact of heating coil valve leakage for inlet air temperatures to the coil

ranging from 15 oC to 30 oC.

4.2 Variable-Air-Volume Boxes

4.2.1 Normal Operation

Figure 4.9 is a schematic diagram of a typical single duct VAV box with hydronic reheat. A

typical control sequence is shown in Figure 4.10. The pressure-independent VAV box has a

damper for adjusting the flow rate of supply air into the room and a differential pressure

transducer (or alternative flow sensor) for measuring the flow rate of air into the room. The air

can also be reheated before it is delivered to the room. A hydronic reheat coil is depicted in

Figure 4.9, although electric reheat is also common. The thermostat is used to measure the room

temperature, and some thermostats allow the building occupant to adjust the set point. Also

shown in Figure 4.9 is a temperature sensor that measures the discharge air temperature from the

VAV box. This sensor is used to provide diagnostic information rather than for control purposes.

Control systems for pressure-independent VAV boxes commonly use a cascade control strategy

to maintain the zone temperature at the setpoint value. A heating set point and a cooling set point

are typically specified. As the zone temperature increases above the cooling set point, the airflow

rate to the zone increases proportionally. This is accomplished by resetting the setpoint value of

the airflow rate and modulating the damper to achieve this flow rate. As the zone temperature

decreases below the cooling set point, the damper gradually decreases until it is providing the

minimum flow rate necessary for ventilation. If the room temperature continues to decrease and

reaches the heating set point, the reheat valve will begin to open. The airflow rate can also be

varied in the heating mode, with the airflow increasing as the temperature decreases.

Alternatively, a higher fixed airflow rate may be specified for heating operation to improve the

distribution of the warm air. In Figure 4.10, it is assumed that a fixed airflow rate associated with

the ventilation requirement of the room is provided in the heating mode.
38

Room

H

C

DP

Hydronic

Reheat Coil

VAV Box Controller

o

Thermostat

T

Damper

Hot Water Supply Hot Water 

Return

M

M

Supply Air

Room

H

C

DP

Hydronic

Reheat Coil

VAV Box Controller

o

Thermostat

T

Damper

Hot Water Supply Hot Water 

Return

M

M

Supply Air

Figure 4.9. Schematic diagram of a single duct pressure-independent VAV box with hydronic

reheat.

Damper

Position

Heating

Set

Point

Cooling

Set

Point

Room

Temperature

Valve

Position

Fully

Open

Minimum 

Position

Fully

Open

Fully

Closed

Damper

Valve

Damper

Position

Heating

Set

Point

Cooling

Set

Point

Room

Temperature

Valve

Position

Fully

Open

Minimum 

Position

Fully

Open

Fully

Closed

Damper

Valve

Figure 4.10. Damper and valve control sequence as a function of room temperature for a single

duct pressure-independent VAV box with hydronic reheat.
39

4.2.2 VAV Box Faults: Implementation and Expected Impact

Stuck Damper

• Fault Condition: Stuck open or closed

• HVACSIM+

 TYPE 525: Motorized pressure-independent VAV box

• HVACSIM+ Unit: Zone 3 VAV box

• HVACSIM+

 Variable: Damper position (0 for stuck closed and 1 for stuck open)

A stuck VAV box damper is implemented by setting the second output variable for the

motorized pressure-independent VAV box TYPE to a constant value. When operating normally,

the damper modulates to maintain the airflow rate to the zone at the setpoint value. A stuck

damper fault will prevent the damper from modulating and will lead to comfort problems as the

zone temperature drifts away from the set point. For instance, if the damper is stuck closed on a

day that requires significant cooling, the zone temperature will increase because the VAV box is

unable to deliver the required amount of cool air. Some AHUs are equipped with a reset schedule

that adjusts the supply air temperature downward if a zone is too warm and the damper is wide

open. In some cases AHUs are also equipped with a reset schedule that adjusts the supply air

static pressure upward if one or more VAV box dampers are wide open. A stuck closed VAV

box damper could trigger one or both of these responses because, based on the output signal to

the damper, the controller believes that particular damper is wide open. In either case, an energy

penalty is incurred.

If the damper is stuck open, occupant comfort could again be compromised. To compensate for

the excess air, the VAV box may need to transition to a reheat mode. In addition, the supply fan

will have to operate at a higher speed to meet the static pressure set point. Thus, it is clear that

both comfort and energy penalties can and do occur when VAV box dampers are stuck open or

closed.

Stuck Reheat Coil Valve

• Fault Condition: Stuck open or closed

• HVACSIM+

 TYPE 321: Motor-driven actuator

• HVACSIM+

 Unit: Zone 3 VAV box

• HVACSIM+ Variable: Position of final control element (0 for stuck closed and 1 for stuck

open)

A stuck reheat coil valve fault is implemented by setting the first output variable for the valve

actuator equal to a constant value. If the valve is stuck closed and the VAV box is operating in

the cooling mode, the fault should have no impact. If, however, the VAV box wants to operate in

the heating mode, hot water will be unavailable and comfort may be sacrificed.

If the valve is stuck open and the VAV box is operating in the cooling mode, the damper will be

forced to open further in an attempt to compensate for this additional load. This will increase the

fan energy use and may jeopardize comfort. In an extreme case, the damper could modulate to

the full open position and cause the supply air temperature set point to be reset to a lower value
40

or the supply air pressure set point to be reset to a higher value to compensate for the additional

load. In both cases, an energy penalty is incurred. If the valve is stuck open and the VAV box is

operating in the heating mode, excessive heating will likely be delivered, forcing the VAV box

back into the cooling mode.

5 SUMMARY AND FUTURE WORK

This report provides a description of the VCBT and the FDD Test Shell; two enabling tools

developed to advance research efforts related to the integration of building control systems and

the development and testing of innovative services such as FDD. The VCBT is a hybrid

software/hardware platform that can be used to test new concepts for control strategies and

prototype products in a way that is economical, efficient, and convenient. The mechanical

equipment and building shell of the virtual building are modeled in HVACSIM+. Control

strategies are implemented in real BACnet speaking control products that interface to the

HVACSIM+

 models through a data acquisition and control unit. Faults associated with sensors

and actuators are modeled in HVACSIM+ and their impacts are observed in the responses of the

controllers. This provides a convenient and consistent way to generate data that can be used to

evaluate the performance of FDD tools embedded in the controllers.

Many of today’s emerging FDD tools are stand-alone software products that do not reside in a

building control system. Thus, trend data files must be processed off-line, or an interface to the

building control system must be developed to enable on-line analysis. The FDD Test Shell

provides a platform for standardizing data exchange among various data sources and FDD

algorithms that utilize that data. The FDD Test Shell includes a BACnet interface that enables

data from BACnet controllers to be accessed and made available to FDD algorithms via a DDE

server table. This interface enables FDD tools to be connected to the VCBT’s BACnet

controllers, thereby providing a testbed for evaluating both performance and communication

issues before the more challenging field tests are undertaken.

Preliminary tests of some of the faults modeled in the VCBT are described in this report. The

primary goal of the tests was to quantify the impact of valve and damper leakage for typical

AHU and VAV box configurations. This was accomplished by performing open-loop tests for

faults of varying severity and recording the thermal effect (temperature rise or drop) created by

the different faults. The testing revealed that leakage through the outdoor air damper and a stuck

open outdoor air damper fault have almost no measurable impact on the operation of the system.

The implication of this finding is that further testing of these faults for current system

configuration and control strategy is not necessary.

In the next phase of this project, the VCBT and FDD Test Shell will be used for both off-line and

on-line testing of AHU and VAV box diagnostic tools for a range of weather conditions. Off-line

testing will be accomplished through batch processing of pure simulation data produced by the

models embedded in the VCBT and will be pursued because it can be done in faster than real

time. On-line testing will demonstrate that the simulated control strategies used to produce data

for off-line testing are consistent with the control strategies implemented in the commercial

BACnet controllers. It will also demonstrate the robustness of the communication between the

FDD tools, the FDD Test Shell, and BACnet products of different manufacturers. This testing

will set the stage for interfacing the FDD Test Shell to BACnet controllers in the field and for

assessing the performance of the diagnostic tools with field data.
41

6 REFERENCES

1. ANSI/ASHRAE Standard 135-1995: BACnet - A Data Communication Protocol for Building

Automation and Control Networks. American Society of Heating, Refrigerating, and AirConditioning Engineers, Inc.: 1793 Tullie Circle N.E. Atlanta, Georgia 30329-2305 (1995).

2. Kelly, G. E., Park, C., and Barnett, J. P., Using Emulators/Testers for Commissioning EMCS

Software, Operator Training, Algorithm Development, and Tuning Local Control Loops,

ASHRAE Trans., Vol. 97, Pt. 1 (1991).

3. Park, C., Clark, D. R., and Kelly, G. E., An Overview of HVACSIM+

, A Dynamic

Building/HVAC/Control Systems Simulation Program, Proceedings of the 1st Annual

Building Energy Simulation Conference, Seattle, WA, August 21-22 (1985).

4. Klein, S.A. et al., TRNSYS: A Transient System Simulation Program, Report 38-11, Solar

Energy Laboratory, Univ. of Wisconsin – Madison (1981).

5. Gear, C. W., The Automatic Integration of Ordinary Differential Equations, Comm. ACM,

Vol. 14, No. 3, pp. 176-179 (1971).

6. Clark, D. R., HVACSIM+ Building Systems and Equipment Simulation Program Reference

Manual, NBSIR 84-2996, NIST (1985).

7. Clark, D. R. and May, W. B., HVACSIM+ Building Systems and Equipment Simulation

Program - Users Guide, NBSIR 85-3243, NIST (1985).

8. Park, C., Clark, D. R., and Kelly, G. E., HVACSIM+ Building Systems and Equipment

Simulation Program: Building Loads Calculation, NBSIR 86-3331, NIST (1986).

9. Haves, P. and Norford, L. K., A Standard Simulation Testbed for the Evaluation of Control

Algorithms and Strategies. ASHRAE 825-RP Final Report. American Society of Heating,

Refrigerating, and Air Conditioning Engineers, Inc.: 1793 Tullie Circle N.E. Atlanta,

Georgia 30329-2305 (1997).

10. Kusuda, K., Thermal Response Factors for Multilayer Structures of Various Heat

Conduction Systems, ASHRAE Trans., Vol. 75, pp. 246-270 (1969).

11. IEA Annex 25, Building Optimization and Fault Diagnosis Source Book, Eds. J. Hyvärinen

and S. Kärki, Technical Research Centre of Finland (1996).

12. Seem, J. E., Park, C., and House, J. M., A New Sequencing Control Strategy for AirHandling Units. International Journal of HVAC&R Research. Vol. 5, No. 1, pp. 35-58

(1999).