Case-study on the application of building HVAC

Case-study on the application of building HVAC performance analysis
and fault detection using ABCAT
Master Thesis
T.M.K. Hissel
June 2012
Technical University Eindhoven
Faculty of Mechanical Engineering
Sustainable Energy Technology Master Program
Unit Building Physics and Systems
In association with Strukton Worksphere
Supervisors:
prof.dr.ir. Jan Hensen (TU/e)
ir. Gert Boxem (TU/e)
MSc. Barry Tuip (Worksphere)
i
Abstract
In many cases buildings do not performs as intended. Shortly after completion, the energy
performance of a building starts to degrade and energy consumption increases.
Conventional building management and monitoring systems do not detect and alarm
decreasing performance, neither is there adequate diagnosis of the cause of this
performance loss. Monitoring, fault detection and smart diagnosis of the energy use of a
building can give a better insight in the loss of performance of building heating and cooling
systems and provide guidelines for improvement.
In this study, which is part of Strukton Worksphere’s development of building management
tools, a case-study is carried out on the application of monitoring, fault detection and
diagnosis on an existing building.
A measurement setup is applied to support the monitoring process and the ABCAT software
(Automated Building Commissioning and Analysis Tool) is used for heating and cooling
energy consumption predictions. Fault detection and diagnosis (FDD) is performed by
comparison of the predicted consumption with measured values.
The applicability of these specific methods on the case-study building has been assessed.
Both simulation and FDD were unsuccessful. Within the scope of the project it was not
possible to realize a calibrated model with sufficiently accurate simulation results, due to the
following reasons:
1. The simulation software (ABCAT) is a prototype which requires more development
into a comprehensive and robust product. Additional testing and expansion on more
diverse buildings and systems is required to exclude compatibility issues.
2. Calibration is applied on a clearly underperforming HVAC system. It is observed and
concluded that various aspects of the HVAC configuration and its control contain
flaws. Simulations represent a correctly working system, while measurements
represent a malfunctioning system with an obvious mismatch in results as a
consequence.
Although the goal of simulation-based FDD has not been reached, several faults in the HVAC
operation are detected. Careful monitoring and detailed analysis of measurement data by
experts, without a simulation reference, has strong FDD possibilities as well.
Based on the case-study results. Conclusions and recommendations on the compatibility of
methods and essential conditions for successful FDD are presented.
ii
Acknowledgements
This report is the result of my graduation project for the Sustainable Energy Technology
master program. Within the SET program I chose to specialize in the Built Environment and
Building Performance Simulation direction because I was very interested in energy reduction
and optimization in the built environment and the transition into a sustainable society in
general. For my research internship and thesis subject I found a pleasant working
environment at Strukton Worksphere, where I did my research while at the same time
exploring the corporate side of the application of building energy optimizations.
First I would like to thank professor Jan Hensen for his overall guidance, good advice and
criticism. I am very glad with the existence of his monthly progress meetings which forced
regular recaps and status inquiry of my work, as well as presenting feedback moments and
presentation practice.
I would also like to thank my direct supervisor Gert Boxem for his guidance throughout the
whole graduation process and his expert review and suggestions to improve this work. I
respect Gert for his knowledge in report writing, being very critical and handing me the best
of tips and recommendations.
Special thanks to Barry Tuip, my supervisor at Worksphere, for showing me all of the
company and assisting me with a lot of practical issues and challenges during the project. I
want to thank Barry for always being very inspiring, motivational and a great colleague. I
also want to thank all my other colleagues at the Worksphere engineering and consultancy
group for their helpfulness and support.
Last but not least my friends and family for being interested in my work, supplying some
good ideas and motivation, proofreading my work (especially my dad who evaluated the
whole thesis in one weekend) and the support through the heavy weeks of thesis-writing.
iii
Contents
Abstract ..................................................................................................................................... ii
Acknowledgements ...................................................................................................................iii
1
2
Introduction ....................................................................................................................... 1
1.1
Problem definition..................................................................................................... 1
1.2
Main goals and objectives ......................................................................................... 1
1.3
Introduction to ABCAT .............................................................................................. 2
1.4
Methodology ............................................................................................................. 3
Monitoring ......................................................................................................................... 5
2.1
2.1.1
Gas-powered Heat Pumps ................................................................................. 6
2.1.2
Air Handling Units .............................................................................................. 7
2.1.3
Induction Circuit ................................................................................................ 8
2.2
Commissioning ........................................................................................................ 10
2.3
Measurement setup ................................................................................................ 11
2.4
Calculations ............................................................................................................. 14
2.5
Data processing ....................................................................................................... 15
2.5.1
Data acquisition, transfer and storage ............................................................ 15
2.5.2
Data processing into useful information ......................................................... 17
2.6
3
Case description ........................................................................................................ 5
Initial building energy performance analysis .......................................................... 19
2.6.1
Energy performance results ............................................................................ 19
2.6.2
Improvements to HVAC system control .......................................................... 20
2.6.3
Energy performance after improvements ....................................................... 20
Simulation and fault detection ........................................................................................ 23
3.1
Background .............................................................................................................. 23
3.2
Simulation with ABCAT ............................................................................................ 24
3.3
ABCAT diagnosis functionalities .............................................................................. 28
3.4
ABCAT compatibility ................................................................................................ 33
3.5
The calibration process of ABCAT............................................................................ 35
3.5.1
The need for Calibration .................................................................................. 36
3.5.2
Required amounts of data ............................................................................... 36
3.5.3
Calibration method.......................................................................................... 37
3.5.4
Calibration evaluation and statistics ............................................................... 41
iv
4
3.5.5
Evaluation of the supplied characteristic signatures....................................... 43
3.5.6
Definition of calibration period and test period.............................................. 45
3.5.7
Application of the calibration process on the case-study building ................. 47
3.5.8
Remaining calibration problems and challenges............................................. 51
3.5.9
Conclusions on the Calibration process .......................................................... 51
Case-study results............................................................................................................ 53
4.1
Building heating and cooling energy consumption ................................................. 53
4.2
ABCAT calibration .................................................................................................... 54
4.3
Fault detection results ............................................................................................. 55
4.4
Diagnosis results ...................................................................................................... 56
5
Discussion ........................................................................................................................ 57
5.1
ABCAT assessment .................................................................................................. 57
5.2
Building energy performance assessment .............................................................. 59
5.3
Expert view versus automation ............................................................................... 62
6
Conclusions and recommendations ................................................................................ 65
References ............................................................................................................................... 68
Appendices .............................................................................................................................. 70
A
Abbreviations .............................................................................................................. 70
B
Detailed description of the ABCAT interface............................................................... 71
C
ABCAT output figures .................................................................................................. 74
D
Sources for ABCAT inputs and building parameters ................................................... 76
E
Characteristic Signatures SWS Son Case-Study Building ............................................. 77
F
Details of subsystem measurements .......................................................................... 83
G
Measurement accuracy, reliability and validation ...................................................... 88
H
Subsystem results ........................................................................................................ 93
I
Details on the HVAC control improvements ............................................................... 95
J
M-files for data processing .......................................................................................... 98
v
vi
1
Introduction
The global energy problem is one of the most important challenges of our time. Depletion of
fossil fuels, increasing energy costs and climate change due to CO2 emissions are
predominant subjects in the media and politics. Reduction of the current and future energy
consumption is one of the ways to face this challenge.
A big share of the worldwide energy consumption is due to the heating, cooling and
electricity demand of existing buildings. The built environment contributes for about 40% in
the worldwide energy use. An obvious approach to attack this energy problem is to focus on
the energy use of climate systems in large buildings and offices. (Elkhuizen & Rooijakkers,
2008) states that about 30% of all buildings uses more energy than necessary and that more
than 70% of all buildings does not function as intended.
Decrease of heating and cooling energy use in buildings can be realized by the
implementation of new, more efficient techniques and devices and furthermore by better
management and control of existing systems. Optimization of climate system configuration
and settings, continuous monitoring of performance and timely, well-directed maintenance
can contribute greatly in the reduction of the global energy use.
Building services contractor Strukton Worksphere participates in this energy reduction trend
by various projects focused on building energy optimization. Worksphere has several current
developments on building management tools, which can be of great help in building energy
monitoring, the discovery of inefficiencies in building energy performance and detection and
diagnosis of faults in the heating, ventilation and air conditioning (HVAC) systems. For this
project a case-study is carried out on the application of monitoring, fault detection and
diagnosis on an existing building. A measurement setup is applied to support the monitoring
process and simulation and fault detection software is used for heating and cooling energy
consumption predictions as well as fault detection and diagnosis (FDD).
1.1
Problem definition
Building HVAC systems malfunction causes increase of energy use. HVAC system
underperformance is often not caused by abrupt faults but by constant, time-scaling
performance degradation (Morisot & Marchio, 1999). Degradation of system performance
leads to increased energy consumption and often also to a decrease of indoor comfort,
according to (Zeiler & van der Velden, 2011). Building services contractors like Strukton
Worksphere make use of PPP (Public Private Partnership) contract forms in which they are
responsible for both energy consumption and indoor comfort of certain buildings. Not
achieving the energy and comfort goals will result in financial penalties so detection of
system malfunction in an early stage is a very desirable development in the building
maintenance field.
1.2
Main goals and objectives
To counter excessive cooling and heating energy use, occurring faults in the HVAC systems
should be detected in an early stage. The assignment for Worksphere is to come with a
1
continuous fault detection and diagnosis (FDD) tool, with proper diagnosis functionality,
which can operate with minimal input of the user. Malfunction of the HVAC systems should
be noticed in an early stage and the cause of problems should be pinpointed and reported.
Wear and tear of parts of the system should be reported so they can be replaced before real
problems or malfunction occur.
Objectives to fulfill this goal:



Detection of faults in the continuous operation of a building HVAC system
Diagnosis of these faults including:
o Identification: distinguish faults from random anomalies and rate the fault’s
impact/urgency
o Isolation: find out in which subsystem or component the fault occurs
Reportage: Automate the process and make sure the right information (develop key
FDD figures) is supplied to building managers and Strukton mechanics by automated
email/SMS alerts.
In this study a measurement setup is assembled and applied for continuous monitoring of
the HVAC system behavior. A method for fault detection and diagnosis is chosen and its
applicability on the case-study building is tested.
Research questions for this test procedure are:
1.
2.
3.
4.
5.
6.
1.3
How is the energy performance of the case-study building?
Is this a suitable case to apply FDD on?
Can we accurately simulate the building behavior?
Can we successfully detect and isolate faults in the case-study system?
Can we make the required measurements setup to do this?
Can we reproduce FDD results from the past (available in literature) on this casestudy building?
Introduction to ABCAT
For simulation and FDD purposes the program ABCAT is chosen (Automated Building
Commissioning Analysis Tool). It is a tool made by the Texas A&M University (Curtin, 2007)
and is especially designed for building energy use diagnosis. The ABCAT can operate with a
limited amount of input data. A simplified physical model of the building and its climate
systems will be calibrated by using measurement data from the building heating and cooling
energy consumption.
Advantages of ABCAT over other simulation software is that:
 A top down approach is used which requires less inputs and detail while the
influence of the fault on the system as a whole will be more clear.
 The data traffic and processing is kept manageable by basing simulation on three
quantities: the total energy use for cooling, the total energy use for heating and the
electricity consumption.
 A simplified model is used which uses less parameters causing it to be easier to
calibrate compared to conventional simulation models.
2
The simplified ABCAT approach makes simulations and FDD more affordable, automated,
and easier applicable.
The energy use predicted by ABCAT is compared to the measured energy use and faults are
detected based on significant deviations between the two. An important feature of ABCAT is
to identify faults that, on the long run, will have a negative impact on the performance of
the HVAC system. These faults can be found by analyzing their cumulative effects. Additional
figures and features are available for further identification and isolation of malfunction.
In this project the ABCAT prototype is applied on a case-study building, the Strukton
Worksphere office building in Son. ABCAT is a relatively new tool which is hardly applied
outside of its own development environment, the Texas A&M University. Case-study tests of
this FDD method, especially focused on compatibility with various HVAC systems and
additional requirements for successful applicability are interesting to research. The
applicability of the ABCAT FDD methods on the case-study building and its conditions is
assessed.
1.4
Methodology
Fault detection will be realized by performing energy use measurements in the case study
building alongside energy use simulations, which will be carried out by an appropriate
simulation program. In a previous literature study (Hissel, 2012) various simulation and fault
detection methods are investigated and compared and the program ABCAT (Automated
Building Commissioning and Analysis Tool) was selected for simulation and FDD applications.
The basic FDD process is summarized in figure 1. It consists of the following steps: 1.)
Monitoring of the real-time heating (HW) and cooling (CHW) energy consumption in the
building. 2.) Physical model-based simulation of the HW and CHW energy use as they would
be in a ‘correctly functioning building’. 3.) Detection, which lies in the comparison of the
measured and simulated behavior and observations of the residual and anomalies occurring
in this residual. ABCAT supplies additional tools and figures for the detection and diagnosis
process which will be explained later.
Figure 1: Schematic representation of the basic 1) monitoring, 2) simulation and 3) fault detection process
3
Throughout the whole study the following approach with sub questions has been used:
1. Monitoring of the case-study building and visualization of the energy use
o Build and configure a measurement setup and data processing treatment that
can support the FDD process
o Inquiry of which parameters are required for FDD and which are already
measured in the building with the existing Building Management System (BMS)
o Complement BMS measurements with additional sensors
o Combine measurement data of different sources
o Validation of measurements and assessment of accuracy
o Process measurements into Input data for simulations and calibration of the
simulation model
2. Simulation of the total heating and cooling energy consumption using ABCAT
o Validation and assessment of ABCAT
o Is it applicable on the case-study building or are there compatibility issues?
o What are shortcomings of and possible improvements for ABCAT?
o How robust is ABCAT and how flexible in the use on multiple buildings?
o Produce an accurately calibrated ABCAT model of the case-study building and
HVAC systems
3. Application of fault detection
o ABCAT will generate time-energy use plots and time-cumulative error plots
o In contrast with the ABCAT baseline and calibration step mentioned before,
ABCAT will now be applied on a different ‘test period’ in which fault detection is
performed
o A proper definition of a fault must be formed. Statistically significant deviations
between measurement and simulation indicate a fault
o Small but persistent deviations, which are not cancelled out, are detected by
their cumulative effect. These are the faults which should be detected because
they indicate with a high probability the malfunctioning of the HVAC system
which should be resolved as soon as possible to prevent excessive energy use
and system break down
o What is the performance of the fault detection of ABCAT?
o Explore and test additional detection and diagnosis utilities provided by ABCAT
o Are faults detected correctly?
4. After fault detection the faults will be diagnosed
o Which diagnosis tools are available in ABCAT?
o Application of the ABCAT ‘expert rule’ tables
o Do the ABCAT ‘expert rules’ work for the case-study building?
o Can the detected faults be isolated to a subsystem?
o Can the faults be pinpointed to a specific component?
o Let Matlab automatically report the likely causes of malfunction. Send this
report to the building operators or Worksphere mechanics
5. Thorough analysis of the achievements and problems regarding the FDD process and
conclusions and recommendations for future projects in this area. The focus lies on
system and software compatibility and essential conditions for successful FDD
application.
4
2
Monitoring
2.1
Case description
The monitoring and fault detection methods are applied on a building in practice. The office
building of Strukton Worksphere in Son, Netherlands was facilitated as the test-case
building. The main advantages of the building are the easy availability and the unlimited
access to all climate and control systems. Because of its state-of-the art climate systems and
short lifetime (no degradation) the building HVAC performance was assumed to be quite
optimal. The monitoring and analysis of the behavior will point out the validity of this
assumption.
The characteristics of the building are:





7 floors of office space
Attached magazine/logistics hall
About 6700 m2 floor area
400 kg/m2 thermal mass
Built in 2010
Figure 2: Test-case building in Son
Figure 3: Floor plan of the case-study building
Figure 4: Design drawing of the building front view
5
Characteristics of the climate systems:





Four gas-engine powered heat pumps for both heating and cooling purposes,
source: ambient air, regular heat pump cycle. 71KW cooling, 84 KW heating each
Additional hot water boiler for peak heating demands
One CAV AHU for office ventilation of about 35.000m3/h air flow capacity, 235 KW
cooling, 150 KW heating capacity and with 60% heat wheel energy recovery
One CAV AHU for restaurant ventilation of about 4.000 m3/h air flow capacity, 40
KW cooling, 40 KW heating capacity and with heat exchanger heat recovery
Heating and cooling distribution by four pipe induction system
The different components of this HVAC system will be discussed in more detail below:
2.1.1 Gas-powered Heat Pumps
The building HVAC system’s main heating and cooling plant consists of four gas-powered
heat pumps from ‘Gasengineering/ Aisin Toyota Group (GasEngineering, 2011)’. A running
heat pump which is either heating or cooling also delivers free engine heat on the side. A
cooling heat pump is able to produce heat at the same time as cooling.
Parameters of the heating and cooling system are found in the ‘building delivery report
(Utiliteitsgebouwen, 2009)’:




Gas engine driven heat pumps
Source: outside air
Heating temperature range: 35°C < Tsupply < 45°C
Backup energy from gas boiler for peak demand






Generation efficiency heating = 1.5
System efficiency heating (system losses) = 0.84
Generation efficiency cooling = 1.95
System efficiency cooling = 0.85
Maximum heating capacity = 336 kW
Maximum cooling capacity = 284 kW
Figure 5: Impression of the Heat pumps and Gas boiler present in the case-study building (Hissel, 2011)
6
Free engine heat
HW buffer
Regular output
Figure 6: Two heat pumps in heating mode (GasEngineering, 2011)
It can be seen that the heat pump delivers an amount of heat equal to Energy from gas *
PER to the heat storage tank. For even better performance also the heat produced by
operation of the engines is delivered to the hot water tank as well. If a specific heat pump is
cooling it can still contribute to the total heat production by supplying the engine heat to the
hot circuit. Part of the energy is lost due to heat loss and the remainder is the heat delivered
to the building.
2.1.2
Air Handling Units
Figure 7: Impression of the AHU's present in the case-study building (Hissel, 2011)
On the building roof there are two large Air Handling Units present from manufacturer
Carrier(Carrier, 2009). The larger one of the AHU’s is dedicated to the office floors of the
building. The other one supplies air to the restaurant and to two meeting rooms.
AHU office:






Heating and cooling coil with water from central heating/cooling plant
Temperature and relative humidity sensors
Heating capacity 150kW
Cooling capacity 235kW
Heat recovery (sensible and latent) by energy wheel, Hygroscopic 310kW
Filtering: synthetic bag filters type F5 and F7
7


Rated air flow 10,3 m3/s
Constant air flow control with two settings (Dahlander Fans, 1500/750rpm)
AHU restaurant:






Heating capacity 43kW
Cooling capacity 37kW
Only sensible heat recovery by heat exchanger, 32kW
Filtering: synthetic bag filters type F5 and F7
Rated air flow 1,6 m3/s
Variable frequency fans, but used as constant air flow
2.1.3 Induction Circuit
The heating in the building is mainly done by an induction heating and cooling system.
Figure 8: Example of an induction segment of an induction heating and cooling system (Trane, 2012)
There is an extensive, branched induction circuit throughout the roofs of all the office area.
All the branches have local valves which make sure the induction segment is supplied by the
right mix of cold and hot water to ensure the correct supplied temperature. Every few
meters a thermostat is present, which directly controls the nearest induction circuit valve, so
the indoor temperature can be adjusted for every single segment and section of the office.
The induction system is a so called four pipe system. There are two supply pipes and two
return pipes for each induction unit. One of both contains hot water, the other one of both
contains cold water. The temperature, or choice between heating or cooling can be made
for each section of the office individually. The indoor climate can be adjusted to the
occupants wishes.
8
Figure 9: The overview of the plant side of the HVAC system, derived from (Priva, 2011) with: The four heat
pumps + engines (which can produce free engine heat), the hot water boiler (red square), the hot and cold
water storage tanks and the hot and cold circuit piping. Temperature sensors indicate the temperature at
various points used for the heat pump control. On the right the water distribution system is connected.
Figure 10: Example of the Priva interface showing the hot water plant, buffer and distribution (Priva, 2011). A
similar distribution schematic holds for the cold water distribution.
A measurement plan is made for the monitoring of the energy consumptions in the building
climate system. The primary purpose of the setup is to get measurement results for the total
Heating (HW) and cooling (CHW) energy use. This is the basis for the top-down FDD
approach which is applied by the use of ABCAT. The total HW and CHW energy consumption
are the main measurement inputs for ABCAT.
Secondary objectives are additional measurements that are assumed to be interesting for
the general energy performance assessment of the building and for the diagnosis & isolation
part of the FDD process. These can be measurements on building level or on
subsystem/component level.
9
2.2
Commissioning
Before being able to apply FDD, a commissioning process is essential, as stated by (Zeiler &
van der Velden, 2011). Initial improvements are not permanent, continuous commissioning
can be a solution. Good commissioning is necessary before setting up a fault detection
system. The continuous checking of a certain level of performance and detection of
deviation from this performance level only make sense when an initial assessment of this
performance has been carried out. Maintaining inefficient behavior would have absolutely
no added value.
The chosen case-study building is the new office building of Strukton Worksphere and
contains a, state of the art, supposedly well performing HVAC system. A thorough
commissioning process has not taken place, though. During the initial phases of the project
it was assumed that the case-study HVAC building would show (close to) optimal energy
behavior because performance degradation over several years of exploitation has not been
the case. Later on in this project this assumption has been invalidated and the
understanding of the need of commissioning has become ever more clear.
In general, commissioning can be seen as an in depth examination and validation of a
building state and its performance (EPA, 2012). The monitoring of a building and detection
of malfunction are no use if the initial state of the building is not assessed by a
commissioning process. Another important aspect of commissioning is that it can bridge the
gap in view and expectations of the building designer, building contractors, building systems
operator and building owner. Because the commissioning process can have a role in all the
phases of a building’s lifetime the visions of all these involved actors can be combined.
There are several types of commissioning that can be distinguished:
 Initial commissioning: Is carried out in the design and production phase of the
building. Before the building is accepted by the new owner the configuration and
working of the climate systems is thoroughly investigated and fine-tuned.
 Retro-commissioning: The commissioning of an existing building that never had an
initial commissioning. From a lot of buildings the performance is never properly
assessed. By retro-commissioning usually a lot of potential energy savings are found.
 Re-commissioning: Commissioning carried out on a building that has had an initialor retro- commissioning in the past. With re-commissioning the building owner can
verify, improve and document the performance of the building and its systems.
 Continuous-commissioning: After commissioning and improving a building’s
systems it is another challenge to avoid the decrease of this new performance. By
continuously monitoring and immediate solving of occurring problems the
performance of the building can be maintained. Fault detection and diagnosis can
have an important role in continuous commissioning.
One aspect of commissioning is the comparison of the target building behavior with
references (Van Kleef, 2011). The following references are often used for comparison:
 Design aspects (Simulation results from building design software)
10



Status report from building completion phase, which should include measurements
from building systems tuning and testing
Measurements in exploitation phase
Reference buildings with comparable specifications
After these comparisons and in combination with basic inspection of the building and its
systems a team of experienced building systems engineers or consultants can bring out a
verdict on the building performance. Is it functioning properly or not? A commissioning
report can also contain advice on which measures have the most potential for
improvements to the building.
When assessing the current performance of the building and systems certain aspects have to
be addressed:



Energy efficiency
Thermal comfort for occupants
Efficient use of equipment (conservation of lifetime)
All these three aspects are important but there is an interaction and often also a
contradiction. For instance if the building’s energy consumption is minimized the thermal
output of the HVAC system can be insufficient resulting in discomfort, or it can lead to
harmful equipment use resulting in early breakdown of system components. A large number
of heat pump startups and shutdowns are disastrous for its lifetime but can on the other
hand be an improvement measure for energy efficiency or guarantee of indoor comfort. It is
important to find the right balance for these and to find an optimum for all three
simultaneously.
Experienced maintenance engineers, energy consultants or other similar professionals can
accurately assess the processes in a specific building case and can also foresee problems
occurring in other aspects of building performance. Where monitoring and fault detection
are processes which can be automated by use of software, this is much less the case for
commissioning. If this is to be automated the software must be able to correctly combine
different aspects of performance which is challenging. Computer intelligence is not expected
to be suitable for all the aspects of building commissioning.
2.3
Measurement setup
The installation and optimization of this measurement system is performed as part of this
graduation project. The Priva building management system is already installed in the
building and inhabits various sensors measuring the climate system status and room
conditions throughout the building. In addition to the measurements from the BMS
additional measurements are carried out with the WiSensys wireless measurement system.
There are about 70 measured quantities available in the Priva BMS. Only the ones necessary
to achieve the project goals are selected and further processed. The choice of measurement
parameters, acquisition and processing of data are steps in the monitoring process carried
out for this project.
11
Acquisition of the total heating and cooling energy use
Ideally the total heating energy use (HW) and cooling energy use (CHW) would be directly
measured at the source (Gas-powered heat pumps) or at the main supply circuits. Various
methods for measuring these quantities were addressed but they all presented some major
obstacles:



Because both the heating and cooling are generated by the same plant (four heatpumps) they are not measurable individually
Climate installation equipment does not allow direct extraction of activity
information (heat pump energy production, circulation pump activity (rpm/flow))
The main supply circuit lacks measurement options. Valves with Δp connections are
occupied by sensors for pump control, alternative (ultrasonic) flow measurements
are expensive and overdone for the scope of this project.
Because of this an alternative was chosen where total HW and CHW energy flows are
determined using individual measurements on the three supply subsystems (figure 11):
Figure 11: Overview of the embranchment of the building systems plant side into the three supply subsystems:
the induction circuit, AHU office and AHU restaurant. This embranchment is similar for the HW and CHW net.
Because the heat flows or energy consumption is not measurable on the plant side these are obtained by the
combination of subsystem measurements


Energy supply to the induction circuit. By measurement of the mass flow and supply
+ return temperatures the supplied HW and CHW energy can be determined.
Energy supply to the heating and cooling coils of the two AHUs can be determined
by temperature and relative humidity measurements in combination with the
produced air flow rate. Special attention is required for latent heat recovery by the
energy wheel in the office AHU.
12
The measurement plan is not the most accurate solution but because of the technical
difficulties of the more direct measurement approaches this is the best achievable
alternative.
Table 1: Parameters measured in the case-study building and the respective measurement systems used.
(Priva BMS = existing measurements from building management system, WiSensys and Maestro are additional
wireless measurement systems, KNMI is meteorological data from nearby weather station)
Parameter
Outside temperature
Outside humidity
Indoor climate
Electricity use
Gas use
ΔP Induction
T Induction
Tsupply, Treturn AHU
Texhaust AHU
Air flow rate AHU
RH AHU
Priva BMS
X
WiSensys
X
X
Maestro
KNMI
X
X
X
X
X
X
X
X
X
X
X
X
Gas Use
The building’s total gas consumption is already measured for energy monitoring purposes. In
this project the gas use can be very useful for validation of energy use results. Energy use
can be calculated by temperatures and energy flows, but also by gas use, energy content
and system efficiency. The comparison of a result obtained by two different approaches can
give very useful information about the correlation and so validate the results .From the gas
use quantities no division between heating and cooling quantities can be made, it can only
be compared to the combined HW and CHW energy use. Gas consumption measurements
come from a meter on the main gas line in of the building and are available in the Maestro
energy management database.
Electricity Use
Electricity consumption is measured both on the main meter and on electricity group level.
The building’s total electricity use is used as an input for ABCAT and is an essential quantity
to measure. Electricity use of individual groups can be useful for fault isolation purposes and
is measured and stored as well using the KNX system and Honeywell data acquisition
equipment.
The overview of the applied measurement setup and all the quantities monitored can be
seen in table 5. Measurements are obtained from different sources and all the information is
gathered and combined using Matlab. Measurement data is stored in a database on a
Worksphere server.
The measurement accuracy and the validation of measurements is discussed in appendix G.
The following paragraph treats the mentioned subsystems in more detail and later on the
calculations and processing required to determine the heating and cooling totals are
explained. Details on the subsystem measurement methods can be found in appendix F.
13
2.4
Calculations
First of all the equation for total heating and cooling energy use
Induction
The measurements supporting these calculations are treated in more detail in appendix F.
AHU office
QAHU is actually the energy supplied to the heating or cooling coil (Qin) which can be derived
from the energy balance of the heat transfer processes in the AHU. Due to its measurement
complexity and assumed insignificance heat losses in the AHU are neglected. In figure 12 a
schematic overview of the AHU is given and important Temperatures and energy flows are
indicated.
Figure 12: Schematic overview of AHU office, as presented in the Building Management System, showing key
parameters for the energy balance and energy flow calculations (Priva, 2011)
AHU energy balance:
The thermodynamics and corresponding formulas of an AHU are treated in (Howell, Coad, &
Sauer, 2009). In this balance Qin can be either positive (heating) or negative (cooling). While
processing the calculations this is taken into account accordingly.
14
The energy recovery using the energy wheel is obtained by the following relation:
Sensible heat recovery by common flat plate heat exchanger:
Energy recovery by energy wheel:
Using the enthalpy given by:
The results of these calculations are presented in the results section (4.2) and the validation
and accuracy of results are treated in appendix G.
2.5
Data processing
2.5.1
Data acquisition, transfer and storage
Figure 13: An illustration of the Matlab program written to automatically gather and transfer the necessary
measurement variables from the building management system to the measurement database on the
Worksphere server
Measurements from the WiSensys sensors are uploaded directly to the server on which the
web-based database utility is running which can be seen in figure 14. The WiSensys sensors
are wireless, battery powered packages of one or more sensors with a transmitter circuit.
Each sensor should have a base-station nearby. A base station has line-power, continuously
receives data packages from one or more sensor units and continuously transmits the
gathered measurement data to the server. The connection to the server is realized through
a mobile phone network.
Measurements from the PRIVA building management system are stored in a MS Access
database present at the PRIVA server. Data transfer from the local database to the WiSensys
database is done by a Matlab program especially written to support this measurement
setup. The steps carried out in this acquisition program are:
- Connection to MS Access database and inquiry of available parameters
15
-
Automatic selection of required parameters
Comparison already acquired data range with the data range on PRIVA database
Import of only the new data
Connection to Worksphere server via php
Upload of the just imported data to the right places in the Worksphere database
Scheduled to automatically run every night. Error report via email if transfer fails
For data storage, the following storage functionalities have been developed and installed:
-
Automatic storage of WiSensys measurements in Worksphere database
Automatic Matlab uploads of Priva data to Worksphere database
All data is combined and made available via web browser as can be seen in figure 14
Data downloads by Matlab via php scripts and database login authentication key
Figure 14: The combined measurement data stored in a database on Worksphere server. Directly available to
Matlab for data processing and also available in a web interface for manual monitoring purposes
The required data is now available in the WiSensys database. The m-file for processing
(Appendix J) downloads the required data columns, applies data synchronization and format
processing and executes the calculations given in the calculations paragraph for each of the
subsystems.
16
2.5.2
Data processing into useful information
Figure 15: Overview of measured parameters and their processing into required input parameters for ABCAT
Data processing tasks as carried out with Matlab include:







Cutting of all vectors to the same length, making all vectors have the same starting
and end point. Vectors lengths are automatically checked and adjusted to match the
shortest one
Removal of NaN’s (Not a Number) and filling of gaps in measurement data by either
average values ore by interpolation of the data in between
Values must be converted to Imperial units
Vectors with different time intervals (3min, 5min, 15min) must be converted to
hourly values and daily averages
Time vectors must be converted from datenum to Unix and dd/mm/yy format
Electricity consumption must be summed to 24hour values
Separate columns must be produced with the correct ABCAT input values (as can be
seen in figure 15) for preoccupied, occupied and post-occupied periods
The processed data can either be copy-pasted, exported to .mat or .txt or directly written to
Excel via the xlswrite functionality. After this process the ABCAT input data is present in the
ABCAT Input tab and simulations can start.
17
Figure 16: Overview graph of the processed measurement data showing daily values for Heating energy
consumption, Cooling energy consumption, Gas consumption and the combined heating and cooling energy
consumption. This figure is used for basic validation and comparison purposes
18
2.6
Initial building energy performance analysis
During the validation and processing of measurement data some observations could be
made. Later on this evolved into a more precise energy performance analysis of the casestudy building involving the assistance of energy consultants and control technicians. The
involvement of these experienced people can be interpreted as being the expert view in the
case-study HVAC system performance analysis. Diagnosis of the building energy
consumption results pointed out inefficiencies in the system operation and plans for
improvements were made and put into use.
2.6.1
Energy performance results
Figure 17: The first energy consumption results yielded interesting observations on the building energy
perfomance: unexpected high amounts of simultaneous heating and cooling are reported in the summer
months indicating energy inefficient behavior
High amounts of simultaneous heating and cooling can be observed in the months august
and September. Simultaneous heating and cooling can occur because it is a four pipe system
for which this is an intended functionality. The amounts of simultaneous heating and cooling
are out of proportions though, resulting in significant energy waste.
The cause of this inefficient behavior is found in the set-points for hot water and cold water
circuits, which have relatively high values throughout the whole year. Hot water (45oC) and
cold water (10oC) are continuously transported through the whole building without being
used. Heat loss and heat transfer between hot and cold pipelines are a direct waste of
energy. The weather conditions in these months were very moderate and the amount of
heating or cooling required to produce a comfortable indoor climate appear to be just
fractions of the actual heating and cooling energy used in this period. The expert verdict on
this matter: ’The building shows very poor energy performance and actions are required to
improve the HVAC control software.’
After these initial observations on system malfunction and the reportage of severe
underperformance, Worksphere acknowledged the energy performance issues and
measures for improvements have been taken. Several improvements to the HVAC control
have been carried out which are described in the following paragraph. Further monitoring
and FDD applications are delayed until these improvements are implemented.
19
2.6.2
Improvements to HVAC system control
Initial
measurements
Observations of
HVAC system
underperformance
Improvements on
HVAC control
software
Measurements on
improved system
and application of
FDD
Figure 18: Overview of the different steps in the building performance assessment + improvement process
A proposal for improvements on the building control system (RTO, (Meulman, 2011) has
been written and is implemented into a new version of the Priva control software. The new
control software is put into use on dec8th 2011 and fine-tuned in the subsequent weeks.
Figure 19: Illustration of the HW and CHW water flows in the induction circuit, that shows the moment of
implementation of the new control software which immediately deactivated the unnecessary cooling which
was previously present in the building.
A short overview of the improvements in the new software:




Summer and winter block
Cyclic switching of the heat pumps
AHU heating curve optimization by use of return temperatures
Heat pump & engine heat - release and set point optimization
The contents of the existing HVAC control strategies and the applied improvements are
explained in more detail in appendix I.
2.6.3 Energy performance after improvements
After the optimizations in the control software the FDD process is continued. As can be seen
in the calibration chapter the period after improvements has been defined and used as the
calibration period. FDD has been applied on the test period, the period before
improvements, in which there is guaranteed underperformance of the HVAC system.
Although many improvement have been carried out, the HVAC energy performance still
appears to be not optimal. During the continuous operation after the optimization efforts
more suboptimal performance and faults in behavior are observed, including:


Slacking outside temperature indicator
Deviations from design in climate installation configuration
20


Buffer tank layering problems and short circuiting
Valve leakage in induction circuits
Moreover results are obtained from a research on the energy efficiency of the same building
but carried out independently (Daelmans, 2012). From this research, energy consumption
simulation results are obtained which are produced using the original design models of the
building and the simulation program VABI. The results are assumed to be correct and are not
further validated. A comparison is made between the simulated annual gas consumption
and the actually measured annual gas consumption. Because the design is likely not the
same as the actually built systems and because the simulations are carried out for a different
year (simulations for VABI reference year, measurements for 2011) it is not expected that
the results show a close match. It is interesting though to validate if the simulations are
anywhere near the measured quantities. This is not the case, the building consumes much
more gas than is simulated in the building design phase. This is an extra indication that the
building is currently underperforming.
Gas consumption for heating and cooling purposes [m3/year]
150000
100000
50000
0
Measured
VABI 117
VABI Elements
Figure 20: Measured heating and cooling gas consumption compared to simulations with VABI. Carried out to
assess the current energy performance in relation with the intended performance.
The calibration of ABCAT has been performed on this period with suboptimal behavior and
the applicability and performance of ABCAT is analyzed. There was no time to delay the
calibration and FDD application a second time. The observation of these additional flaws in
the system is relatively new, no actions for improvements have been initiated until now.
The observed flaws in HVAC system operation are:
Delay in outside temperature indicator
Cold nights and sunny days in march. Cooling is controlled using a damped version of the
outside temperature. It takes the average outside temperature over the past few hours.
When this delayed outside temperatures increases over the set-point outside temperature
the building cooling system is activated.
In the morning the slacking temperature will rely heavily on the cold night temperature. On
a sunny day, where high solar irradiation heats up the office space the temperature for
cooling control will fall behind. The cooling will not activated despite of high indoor
temperatures. In the afternoon people start to go home and the occupancy decreases. The
delayed control temperature now inhabits a large share of the warmer temperatures from
during the day and will have a high value. The cooling increases while there is no more
demand and use for it.
21
Deviations from design
In the current HVAC configuration wrong
pipeline connections are reported, resulting in
hydraulic unbalance (Daelmans, 2012). The
engine heat supply pipeline is connected on the
wrong place which causes counteracting flows,
as is shown with blue arrows in figure 21.
Buffer tank short circuiting
For the heating circuit the supply temperature
(Tsupply) should always be higher than the
return temperature (Treturn) because the
water in the heating circuit delivers heat to the
building. It is observed that sometimes the
return temperature after the buffer tank is
higher than the return temperature before the Figure 21: Schematic of hot water distribution and
buffer tank showing: Hydraulic unbalance in heat pump
tank (Treturn). This indicates there is a direct
connection and supply and return temperature
indications, related to the buffer tank short circuiting
flow (indicated in figure 21 with a purple
(Priva, 2011).
arrow) from the buffer tank into the return
water stream, which is actually the buffer tank short circuiting.
Valve leakage
After the application of the new control software on December 8th the circulation of
induction cooling circuit is shut down. In figure 22 can be seen that after this change the
temperature of the cooling circuit rises quickly to a temperature similar to the heating circuit
average temperature. Off course the temperature of stationary water will adapt to the
ambient temperature and this ambient temperature can be influence by the heating circuit
pipelines which are situated alongside the cooling circuit ones. According to HVAC
technicians the rate of change of this temperature rise does indicate that there is a leakage
between the HW and CHW circuit, most likely caused by leaking vales. This leakage is a
direct transfer of heat and could be a huge waste of energy, which is very unwanted.
Figure 22: Measurements from the HW & CHW supply and return temperatures showing a high rate of change
of the CHW circuit warming up after circulation shutdown.
22
3 Simulation and fault detection
3.1
Background
Before any kind of FDD can be applied, first the correct or normal behavior of a system or
component must be known. If incorrect behavior is observed the necessary improvements
must be carried out to achieve correct behavior and define a base case situation. In order to
guard and maintain the energy improvements and system performance realized by the
commissioning process it is required to continuously monitor the building performance and
detect faults in the HVAC functioning. In the literature study report (Hissel, 2012) several
FDD methods are compared and their possibilities are assessed. A promising and interesting
FDD tool is ABCAT. ABCAT is chosen for FDD applications in this study. Some more detail on
a suitable simulation and FDD approach is given below:
FDD approach
In the analysis of the behavior of a system two approaches can be distinguished: The bottom
up and top down approach. Both approaches are investigated and compared . For an
affordable, easy to implement and automated FDD system the top down approach is the
better option to get to a total building energy analysis and to keep the data processing
manageable. ABCAT makes use of the top down approach (Curtin, 2007). In the top down
approach the detection of faults is carried out using information from only the highest level
of the target system, in this case the total heating and cooling energy consumption. For
further analysis it is possible to address lower levels of the system.
Method for simulation and FDD
Various model-based and statistical regression methods are compared in the research
internship (Hissel, 2012). For the model-based methods both the first principle (white box,
physical model based) and data driven (black box) approaches are compared. All these
approaches have their advantages and disadvantages but still all of them are viable for
building FDD and deserve and require additional research in the development of FDD as a
whole. As sated before, for this project a physical model-based simulation method is chosen
in the form of ABCAT (Curtin, 2007). In the model-based FDD process, first simulation results
of the target building are obtained. Fault detection is then carried out by comparison of
simulated results with measured results and the analysis of the simulations-measurement
residual (also called analytic redundancy).
Not every anomaly detected in the system behavior is necessarily an indication of system
malfunction. Real faults in the system must be separated from randomly occurring
anomalies by means of identification. After fault detection and identification the question
remains in what part of the system the fault occurs. For this step in the FDD process the
total heating and cooling energy consumption measurements are not sufficient and
additional measurements on component level have to be included. Analysis of component
level measurements by an expert rule system will be used for the isolation purposes in the
case-study project.
23
3.2
Simulation with ABCAT
By physical model-based simulations, ABCAT will supply predictions for the energy use of the
building for heating and cooling purposes. With ABCAT, faults can be detected making use of
analytic redundancy, which is the analysis of the residual between the measured energy use
and simulated energy use. Significant deviation (exceeding a certain threshold) will be an
indication for an anomaly, which is a possible fault in system operation.
Detection of a one-time deviation between measurement and simulation does not
necessarily indicate a real fault. One way to identify a real fault is by adding the analysis of
cumulative deviations. Without speaking of abrupt faults, a system can show a constant
time-scaling performance degradation. Real faults (malfunction) are often not a onetime
occurring deviation but are persistent for a longer time. With the proper tools and figures
presented by ABCAT, real faults can be identified.
ABCAT is an Excel-based program. The interface (input specification and output numbers
and figures) consists of various sheets in which inputs and parameters are supplied and
numerous output figures are presented. The physical model behind de simulations is present
in several Visual Basic macros and will not be visible or of any use for the common ABCAT
user.
The physical model
For simulation ABCAT makes use of physical models of the HVAC system and its
components. The models are based on the ‘Simplified Energy Analysis Procedure’ (SEAP)
(Knebel, 1983) and can predict the cooling and heating energy consumptions using
simplified procedures and only a limited amount of input. Additional characteristics of the
SEAP include:




Simulations are run on a daily average basis, applied on both the input variables and
the output data. This is sufficient for the FDD purpose of the program.
The model allows the specification of a fraction of the measured electricity
consumption that is converted into heat gain within the building.
The building is represented as a two zone model: the exterior zone (subjected to
building envelope loads) and the interior zone, which has shown to be an adequate
simplification in modeling (Curtin, 2007).
Systems with similar functionality can be consolidated into a single system.
To be able to simulate various kinds of HVAC system setups ABCAT presents four basic
‘system types’ available for modeling (1 in the schematic). The basic system types are:




Single Duct Reheat (SDRH)
Single Zone Heating and Cooling (SZHC)
Dual Duct Variable Air Volume/Constant Volume (DDVAV/DDCV)
Dual Fan Dual Duct (DFDD)
The specific HVAC system configuration can be modeled by choosing the most appropriate
system type and modify it to represent the system. For the case-study building the Single
24
Duct Reheat model is the most suitable, modifications include: no economizer, 100% OA and
heat recovery.
Building zones
In ABCAT the building is represented as a two zone model, consisting of the interior zone
and exterior zone (all areas subjected to the building envelope). The model is divided this
way because of the physical differences in building envelope loads (solar transmission and
conduction losses). The two zone building model shows to be an adequate simplification in
modeling (Wei, Liu, & Claridge, 1998).
The interior zone area (%) is one of the ABCAT simulation parameters. As can be seen in
figure 3 in chapter 2.1 about all of the building area is subjected to the envelope so the
interior zone area is estimated at 10%. The calibration process of the ABCAT model later on
shows that alteration of the interior zone area hardly influences the simulation results. This
appears to be a very insensitive building parameter.
The operation of ABCAT, its required inputs and the produced output are explained in the
schematic overview below:
25
26
ABCAT operation details
Resolution
All the time-dependent inputs and outputs used in ABCAT are treated on a daily basis.
Temperatures and humidities are used as 24 hour averages. Energy consumptions are used
as total consumption over 24 hours. The use of daily values instead of hourly values (or even
smaller) makes sure that the data handling remains manageable. Also the ABCAT developers
point out that daily consumption data at the whole building level can provide enough detail
to identify and diagnose faults that have a significant effect on energy consumption in
buildings.
Units
Because ABCAT originates from the U.S.A. imperial units are used instead of SI units. To
streamline the ABCAT use and calibration processes the units are not changed during this
project, the required conversions are made accordingly. For FDD purposes the output data is
treated in a relative way, the units are not important for detection and diagnosis results. In
case SI units are important for the presentation and comparison of results a conversion will
be made. The following units are present in the ABCAT:
Table 2: overview of the SI and Imperial units for important ABCAT quantities
Quantity
Temperature
Humidity
Thermal energy
Length
Mass
Volume flow
Unit SI
[°C]
Relative humidity [%]
Joule
Meters
Kilograms
3
m /s
Unit ‘Imperial’ (ABCAT)
[°F]
Dewpoint temperature [°F]
MMBtu(British thermal unit)
Feet
Pounds
2
cfm/ft
All essential inputs have been discussed. With these inserted in the program, simulations
can be run. Simulation produces two columns of output data: HW and CHW energy use.
Automatically all the ABCAT output figures will be generated and updated with the new data
for the desired time-range.
In appendix B the full ABCAT interface and all its inputs and outputs, with their sources, are
treated in more detail. The complete set of output figures is treated in appendix C. The most
important output figures and their use in the FDD process are discussed below. Before
starting to work with ABCAT it should be checked whether the ABCAT models are
compatible with the case-study climate system (3.4) and a calibration process has to be
carried out to optimize the ABCAT results to represent the building systems behavior
accordingly (3.5).
27
3.3
ABCAT diagnosis functionalities
The diagnosis process consists of three parts: detection, identification and isolation. In this
paragraph the measured HW and CHW energy use (the total energy use for heating and
cooling) is mentioned regularly. These are produced from measurements on the case-study
building.
Detection
ABCAT produces energy consumption predictions and presents them in various figures. The
following output figures have the specific purpose of anomaly detection and analysis and are
expected to be useful for the current project:
#1: Time – Energy consumption
Figure 23: Example of the regular time-energy consumption plots of both the measured and the simulated
energy consumption used for detection. Similar for both HW and CHW. Significant deviations are detected but
are not necessarily faults (Curtin, 2007).
ABCAT produces a variant for HW and for CHW energy use. Both the measured and
predicted energy consumptions are presented. Statistically significant deviations between
measurement and prediction indicate a possible fault but a single-time occurring deviation is
not a guaranteed fault. Random anomalies can also cause a large deviation, which in case of
an anomaly usually disappears just as sudden as it appears. The single time occurring faults
are hard to keep apart from single time occurring anomalies. Additional diagnosis is
necessary to identify the real faults from other anomalies.
Small, persistent deviations will not stand out in the normal time-energy plot. Other figures
are more suitable to point these out.
28
#2: Cumulative residual
Figure 24: Example of the cumulative residual plot used to detect small but persistent deviations. Small,
persistent deviations are a strong indicator for real faults in system performance (Curtin, 2007).
In this figure the cumulative value of the residual (measurement – prediction) is plotted as a
function of time. If the residual alters between positive and negative the effect will be
cancelled out and there will not be a clear, overall trend in the cumulative figure. A real
fault, which can be indicated as a constant too high energy use (positive residual) will stand
out in these figures. The cumulative residual appears to be a good indicator of the
significance of a fault. The value of ABCAT does not lie in daily short-term observations but
rather in observations on the order of weeks to months. However, the cumulate plot has
plenty of use for identification.
#3: Consecutive days of excess consumption levels
Figure 25: Example of a consecutive days of excess consumption plot which indicates the persistence of
deviations by showing the number of days a fault persists (Curtin, 2007).
A slight variation of the previous cumulative plots in which the days of excess energy
consumption (anomalies) are counted and plotted as bars. Anomalies lasting for a short time
are cancelled out and disappear after a short amount of time. Anomalies persisting for
multiple consecutive days will be emphasized in these plots. Lasting anomalies are an
indication for faults. The cumulate plot has plenty of use for identification.
29
#4: Outside temperature – energy consumption
Figure 26: Example of a plot showing the energy consumption related to the outside temperature making it
time-independent. These figures are used to detect and identify structural fault patterns, for example schedule
related faults. The red circle indicates HVAC operation in weekends, which is less than on working days
(Peitsman, Aker, Claridge, & Bynum, 2010).
These figures show a different, time-independent relation between measurements and
simulations. Single deviations from the main trend of temperature-energy use will in most
cases be random anomalies happening. Usually there is a second trend, being lower than
the main trend shown. This second ‘branch’ originates from measurements and simulations
in the weekend. During the weekend the HVAC equipment is used less. The outside
temperature dependent plots show different relations than the time dependent plots do.
Different faults can be found using these plots.
#5: Temperature – energy consumption for subsequent periods
Figure 27: Example of the energy consumption for subsequent periods plot used to identify degradation of
performance over time. Higher energy consumption levels indicate malfunction (Peitsman et al., 2010).
Translation of the graph along the y-axis is an indication for change of the system
performance over time. An increase shows degradation of performance. A decrease
indicates an overall improvement of the system performance, most likely caused by
improvement measures taken. Translation and variation along the x-axis is due to variation
in weather conditions and overall scatter in results. It does not give information on the
buildings energy use behavior.
In most simulations one or more of these visualizations of the simulation-measurement
relation will definitely show anomalies. The next step is to identify the anomaly. Is it a
regular inaccuracy of disturbance or is it system malfunction?
30
Identification
Identification is all about separating real faults in the system behavior from regular
disturbances or spread in simulation results. ABCAT supplies some figures to aid in this
process (as shown in the detection part) but the actual identification should happen by user
observation. There is no specific functionality for identification in ABCAT.
With the combination of the normal threshold exceeding + cumulative identified faults the
indication for malfunction can be quite good. Randomly occurring disturbances will not be
present in the cumulative analysis.
Logs of maintenance, replacement of components, power blackouts and other clearly
observable events influencing the HVAC operation are an important aid in testing the
detection and identification capabilities in the testing and assessment step of an FDD
application.
Isolation
The purpose of isolation is to point out in which section of the system the fault takes place.
For this step usually additional, subsystem or component level measurements are required.
The total building energy use, as simulated by ABCAT does not give any information on
subsystem level so the ABCAT output figures have no direct functionality in the isolation
process. Isolation is mainly carried out manually and based on analyst experience.
The diagnosis method used together with ABCAT (Curtin, 2007) explains how partial
isolation can be carried out using the Expert rule method, which is based on the field
experience of climate system experts. For the expert rule method the total HW and CHW
energy consumption is used in combination with the outside temperature, supply air
temperature and economizer deactivation temperature. The economizer is a control part in
the AHU which toggles between use of indoor or outdoor air in relation with the ambient
and required supply temperatures.
31
Table 3: The expert rule table, as presented in (Curtin, 2007). The expert rule method uses the total HW and
CHW energy consumption in combination with the outside temperature, supply air temperature and
economizer deactivation temperature in order to determine the category in which the fault is likely to be.
The simplified expert rule diagnosis method, used with ABCAT, brings down the complexity
of an extensive fault list approach by focusing on a few categories in which the faults are
most likely to happen. The seven fault type categories can be seen in the expert rule table
(table 2).
In the left column of the expert rule table, the likely to occur types of faults are presented.
On the right side of the table, columns are present for different temperature ranges:
-
Outside temperature < Supply air temperature
Supply air temperature < Outside temperature < Economizer shutdown temperature
Economizer shutdown temperature < Outside temperature
For each temperature range the simulated and measured energy use are compared.
Whether the residual is strongly positive, strongly negative or within the expected limits
gives an indication towards one or more of the fault categories. If a fault with a specific
pattern of heating and cooling is observed in only one temperature range, three or four of
the fault categories may apply. As more data is gathered from one or more of the
temperature ranges, the possibilities for a more deterministic diagnosis improve.
Apart from the expert rule method, for this case-study project there are several subsystem
measurement results that can be used to point out the malfunctioning subsystem. Detailed
isolation on component level is significantly harder because there is less information
available and the search gets extended and more complicated. The isolation capabilities with
the approaches mentioned will be investigated .
32
3.4
ABCAT compatibility
All the required predictions, figures and tools for diagnosis will be produced with ABCAT.
The methods available for detection and isolation of faults are investigated and can be
applied after accurate simulation results are obtained. Whether the simulations carried out
with ABCAT yield accurate results is strongly dependent on the compatibility between the
simulations models and the actual HVAC system being simulated. Are the correct physical
models available in ABCAT?
The compatibility of ABCAT is addressed by investigation of restrictions and requirements
presented in the documentation and by comparison with reference (successful) projects.
The system restrictions stated in the ABCAT documentation give some basic requirements
that the building HVAC system must meet. The HVAC system basics show a close match:



AHUs (Single duct, hot and cold coil, no economizer, heat recovery)
Single duct CAV (which is one of the options in ABCAT)
Heat pumps + boiler as central plant (the HW, CHW plant is not discussed in the
documentation)
Available System Types in ABCAT:
1.
2.
3.
4.
SDRH: Single Duct Re Heat (VAV and CV)
SZHC: Single Zone Heating and Cooling
DD: Dual Duct (VAV and CV)
DFDD: Dual Fan Dual Duct
The building shows the best match to system type 1, which will be used for further
simulation. The case study HVAC setup does meet the system type requirements. Next to
requirements for the core HVAC system type there are additional system configuration
assumptions that have been confirmed as well, as can be seen in table 3.
Table 4: ABCAT system configuration assumptions with their validity for ABCAT
System configuration assumptions
The conditioned area is served by single duct
AHUs
Both the supply and return fan have a VFD
Economizer mode with interlinked relief air, return
air and outside damper
AHU coils receive HW and CHW water from a
central plant
The CHW and HW circuits have VFD circulation
pumps
Preheat coil and humidifier are not used in this
system
Compatibility
+
±
±
+
+
+
Remarks
Supply fan = fixed but ABCAT does accept
fixed frequency after all
Economizer is absent and can be toggled off
in ABCAT
Most of the configuration assumptions are met without a doubt. Two of them show a slight
difference in the exact definition, but the ABCAT parameter sheet shows that these
deviating components can be excluded from simulation, which makes these configuration
incompatibilities irrelevant. The case-study HVAC system does meet the configuration
assumptions.
33
Comparison current HVAC system with systems treated in literature
In literature (Claridge & Lin, 2009; Curtin, 2007; Peitsman et al., 2010) a lot of examples are
available of FDD projects successfully carried out using ABCAT. By comparing the HVAC
setup and building characteristics of these successful projects with the setup in the casestudy building more insight can be obtained on the likely compatibility. Test cases of this
type of FDD in real buildings provides the most realistic and valuable feedback on successful
application and compatibility with building systems.
Compatible HVAC setups found:
Sbisi Dining Hall (College Station, TX)
Dining facility, 19 AHUs for all heating and cooling purposes, SDVAV and SDCV with terminal
reheat, operation only during working days and hours, thermal energy (chilled water (CHW)
and hot water (HW)) supply from central utility plant.
Computing Services Building (Austin, TX)
Computer test laboratories and offices, SDVAV units with economizers and mixed air preheat
for interior zones, DFDD units for exterior zones, energy intense computer laboratories are
complemented with extra cooling fan coils.
DASNY Corporate Headquarters (Albany, NY)
Office space, two chillers and five boilers for CHW and HW generation, twelve SDVAV AHUs
with mixed air preheat, economizers and terminal reheat and hot water radiant heating.
OPPD Energy Plaza East Building (Omaha, NE)
Office space, SZHC AHU with economizer and four SDVAV AHUs with terminal reheat and
economizers.
Vertigo Building TU/e (Eindhoven, NL)
Offices and general study space, one heat pump and two boilers as CHW and HW plant, four
AHUs with heat recovery, convective radiators and a four pipe climate roof for heating and
cooling distribution.
The Vertigo building represents the case-study setup best. Successful simulation and FDD on
this building strengthens the assumption that there will be no compatibility problems
between ABCAT and the Strukton case-study building. The fact that gas-powered heat
pumps are used as heating and cooling source in the case-study does not present any issues.
In the FDD projects from literature the CWH and HW source is always mentioned as
‘Thermal energy from central plant’. The source and type of device generating the heat and
cold is irrelevant.
Most of the presented HVAC systems make use of only AHUs for heating and cooling of the
building. A wide variation of AHU types are successfully simulated in the past so it can be
presumed that the modeling of the case-study AHUs will not likely be a problem. However,
34
additional devices for heating and cooling distribution, like radiators, induction heating and
floor heating are not treated in these projects. This raises question on the extend of the
compatibility of ABCAT with these systems.
Because of the correspondence of systems in the case-study building with the systems
available in ABCAT and the close match with the Vertigo case-study, which was successful,
it is expected that ABCAT can be applied without direct compatibility issues. On the other
hand compatibility must not be taken for granted and incompatibility could still cause
deviating results in the further steps of the simulation and FDD process.
The data acquisition and insertion in ABCAT has been successful. ABCAT simulations can be
run without much trouble. The results from the initial simulations, however, do not correlate
well with the measured CHW and HW energy use. As can be seen in (Curtin, 2007), this is
very common for the first simulation rounds of a new building in ABCAT. The ABCAT model
must be calibrated to adjust the simulation results to match better with the measurements.
3.5
The calibration process of ABCAT
In order to be able to successfully simulate the cooling and heating energy use of a building
the calibration to actual measured heating and cooling energy consumption has shown to be
an essential step.
While reading some ABCAT oriented reports (Curtin, 2007; Peitsman et al., 2010), the unique
calibration functionality of the program is mentioned numerous times but how this function
works or how it is applied is never explained. Concerning the functioning of ABCAT, the
program is filled with various Macros that contain all of the simulation processes of the
program. Initially this calibration functionality was expected to be present in these Macros
as well. Because of the lack of Excel macro experience, it was not possible to find and use
the calibration function within these macros. The calibration functionality remained a
mystery for a long time and only after sending out various help requests to experienced
ABCAT users an answer was found:





Calibration is carried out manually instead of automated with Macros
Calibration happens by alteration of building parameters, there are no specific
calibration parameters
Manual calibration happens to be a process by altering values for several iterations and
switching to simulation result figures to see the improvements and make further
adjustments
Statistics will guide the calibration process, statistic metrics comparing the simulation
and measurement results are available in the ABCAT interface
A manual for calibration was obtained (Claridge, Bensouda, Lee, & Wei, 2003)
The manual calibration process to achieve this agreement between simulations and
measurements appears to be time-consuming. The calibration process can be optimized and
speeded up using a proofed methodology for rapid calibration explained in the “Manual of
procedures for calibrating simulations of building systems“ (Claridge et al., 2003). This
manual introduces the use of calibration signatures, that characterize the difference
between measured and simulated performance. Specific calibration signatures are available
35
which are suitable for the four different system types: SDVAV, SDCAV, DDVAV, DDCAV.
These system types are not the same as the system types present as ABCAT physical models
(Chapter 3.2), although they have strong similarities and can be used together. Individual
sets of calibration signatures are available for different climate types. The method for
calibration and its application will be further explained in this chapter.
3.5.1 The need for Calibration
Conventionally the inputs for energy simulations of buildings have been based on design
data. From the experience of the authors, who have carried out hundreds of energy
simulations, it can be seen that differences of 50% or more between simulations and
measurements are not unusual. These differences are not thought to be due to errors in the
simulation software itself, but more likely due to errors in the assumptions of input
parameter values for a particular building, due to misunderstanding of the building’s design
or to the differences between the design and as-build conditions and parameter values.
Various techniques for calibration exist, which either measure or infer the characteristics of
individual buildings as they were built and operated and identify candidate changes in model
inputs that may resolve the differences. The improvements in the correspondence between
the simulated and measured consumptions realized by calibration found by the authors are
deviations of less than 5% on a yearly basis and 5-10% on a monthly basis. Once a probable
error in a simulation input has been identified, the analyst must typically assess whether the
change makes physical and intuitive sense.
Calibration processes in general are time consuming and require a great deal of specialized
expertise. A procedure that can quickly produce a reliable calibration for simulations of large
commercial building HVAC systems would be very valuable.
Uses for these calibrated simulations are:
 References for energy audits of existing buildings
 Energy savings determination after a retrofit
 Estimation of potential energy savings for different virtual scenarios
 Continuous fault detection and diagnostics
3.5.2 Required amounts of data
Regular model based simulation programs can require large amounts of input parameters of
which a few dozen are crucial to the simulation results. In case that simulations are carried
out on a short time period and/or with large increments (for instance monthly values) it
could happen that the number of parameters that can be varied exceeds the amount of data
points that are being fit. In this case the model for this simulation will be ‘mathematically
over determined’. There will be more equations than unknowns. Even if a strong
correspondence between measurements and simulation results is achieved by calibration,
this will not necessarily be the case for future data as well.
Calibrations carried out on problems with insufficient amounts of training data are not
guaranteed to be reliable for further predictions. It is advised to use at least several months
of daily consumption data for the calibration process to eliminate this problem. For the
calibration of ABCAT in this project only a period of four months was available. This four
36
months of daily energy consumption data is not guaranteed to be sufficient. Ideally a larger
amount of data should be used for calibration but this was not possible in the scope of the
project. Depending on the calibration and simulation results it can be concluded whether
the data set is sufficient or not.
Another key requirement for the calibration data set is that the simulation period covers
enough of the annual ambient temperature range. Preferably the whole year is covered and
multiple years is even better to have more extreme weather situations covered. For the
calibration in the case-study period (January – April as will be explained later) this variation
in temperature is not fully covered.
The use of hourly data (or even smaller increments) is another possibility, although it has a
major downside. Dynamic effects of thermal and other fluctuations that happen over the
course of the day will become more evident and can cause problems in the calibration
process. Using daily consumption data these effects will be averaged out and will have no
effect, which makes the use of daily data the most common choice. Hourly data can still be
used for calibration fine tuning but it is not addressed during this project.
The quality of the measured data is also an essential factor to the success of calibration. The
data quality is assessed and addressed in appendix G. Identification and fixing of erroneous
and missing data is an important step to take before starting a calibration procedure. In
some cases it is appropriate to interpolate in order to fill gaps in the data range, while in
other cases it is better to remove erroneous parts from the measurement range. In the
measurement data validation chapter (Appendix G) and the data processing chapter (2.5)
the quality of available measurement data is assessed.
3.5.3 Calibration method
Calibration is carried out using the calibration signature method, it enables experienced user
to calibrate a building with large built-up systems in 10-40 hours. This calibration approach
has been successfully demonstrated in test cases with ABCAT and other simulation
programs, carried out by people from Texas A&M. No doubt this will also be a suitable
method for calibration of the ABCAT simulations in this project.
The calibration of ABCAT is explained in the schematic overview.
37
Figure 28: Schematic overview of the calibration process for ABCAT. All steps in this overview are treated in
more detail in the text.
2) Calibration Signature
The calibration is based on a specific graphical representation of the difference between
simulation results and energy use measurement, which is called the ‘calibration signature’.
(Wei et al., 1998) found out that calculating the difference between measured heating and
cooling consumption and the consumption predicted by uncalibrated simulation,
normalizing them and plotting them as function of the ambient temperature, provides
useful information about the required changes in input variables. Energy uses are
represented against the outside temperature in order to make most of the calibration a
time-independent process.
The only aspects of calibration in which time stays an important factor is the calibration of
the differences between workday and weekend HVAC operation. These differences are
mainly dependent on: building occupancy schedules, HVAC weekend schedules and
weekend electric load (Internal gains). Calibration of the weekend behavior should be
carried out using time-based figures.
For a given system type and climate the graph of this simulation-measurement difference
against the outside temperature has a typical shape which is directly related to the cause of
the difference. In order to make the characteristics more distinctive a second order
polynomial fit of the simulation-measurement residual is used to eliminate a wide spread
and to give a clear overview of the main trend. The actual calibration signature is obtained
as follows:
38
The figure below shows an example of the use of the calibration signature. The
measurement-simulation graph shows that the simulated cooling consumption for low
outside temperatures is much too high. The calibration signature on the right shows the
same information but then in a more distinct way and also tells which profile of change is
required in order to get a closer agreement, as will be explained below. The next step is to
find out which alterations to the simulation will result in a large CHW energy use decrease
for low temperatures while not changing the energy use for high outside temperatures.
Figure 29: CHW Measurement-simulation relations for the same situation. Left: individual measured and
simulated consumptions. Right: Edited variant showing the CHW simulation-measurement residual as a
calibration signature. Note that this calibration signature always has positive values, decreases with increasing
outside air temperature, is about 60% at 35°F and reaches zero at about 75°F. These are characteristics of the
occurring deviations that will be useful to determine what errors are present in the simulation inputs.
Calibration signatures are typically calculated on a daily average basis, but other time steps
are possible as well. The energy consumption values can be whole building or specific
system consumption. They can originate from electric or thermal data and will end up being
dimensionless. Because ABCAT is used for the simulations it will be the total HW and CHW
energy use in MMBtu/day.
3) Characteristic signatures
Next to the calibration signature, which illustrates the current measurement-simulation
deviations, the calibration method makes use of ‘characteristic signatures’. These are again
normalized plots, but this time they reflect the changes in simulated energy consumption as
a result of the alteration of a specific input parameter. The characteristic signature is defined
as:
By comparison of the calibration signature of an uncalibrated simulation with a variety of
published characteristic signatures an indication can be found on which input parameters to
change in order to improve the simulation results. A library consisting of several
characteristic signatures is included with the calibration manual but it is also possible to
calculate new characteristic signatures using any simulation program, so also with ABCAT.
This is done by simulating the building with one value for an input parameter, the baseline
run. Then changing that same input parameter by a given amount an rerunning the
simulation. The change in simulated energy consumption is the basis of the characteristic
39
signature for that specific parameter change. The characteristic signature shows all changes
in terms of the percent change relative to the maximum value of the energy consumption in
the baseline case. Again the characteristic signature is displayed as a function of the outside
temperature. The characteristic signatures can also be seen as a parametric sensitivity
analysis of the building and HVAC system of interest.
CHW (%)
0
-10
20
40
60
80
100
Outside Temperature (F)
V_eDsqft - 0,01cfmft
10
HW (%)
V_eDsqft - 0,01cfmft
10
0
-10
20
40
60
80
100
Outside Temperature (F)
Figure 30: Example of a characteristic signature. By decreasing the exterior zone air flow the chilled water
energy use will remain unaltered. The hot water energy use will increase slightly though. The signature has a
negative slope so The figures below show an example of a characteristic signature. By decreasing the exterior
zone air flow the chilled water energy use will remain unaltered. The hot water energy use will increase
slightly though. The signature has a negative slope so the hot water energy use will increase more for low
outside temperatures than for high outside temperatures. Also the percentage of change is given which is a
good indication for with which magnitude the specific input parameter should be changed in order to match
the simulation calibration signature.
The clues provided by the characteristic calibration signatures are much clearer when CHW
and HW signatures are combined. These two will typically show different trends, and the
combination is a powerful indicator of the input parameter that need to be changed in order
to improve the simulation results.
3) Weather signatures
The characteristic signatures are not only dependent on the specific input parameter and
the type of HVAC system being simulated, but also on the weather conditions for the
building-system location. The signatures clearly depend on the outside temperature. But
also, although not explicitly shown, they depend on the ambient humidity levels when these
are high enough to induce latent cooling loads. Because of this the signatures will be
different for sites with different weather conditions. This is treated by categorizing different
sets of characteristic signatures for different weather characteristics. Characteristic
signatures can be reused from weather signatures that match the weather signature of the
site in question.
40
Eindhoven, NL
20 30 40 50 60 70 80 90 100 110
Outside Temperature (F)
Figure 31: The weather signatures used in the manual (Claridge et al., 2003) and the weather signature for
Eindhoven.
The weather characteristics are found by plotting the relative humidity with respect to the
outside temperature for Eindhoven for a long time period. This characteristic gives a clear
representation of the present climate type. Using the best fit regression the big cloud of
individual data points is processed to an overall, single line, trend. Weather data is derived
from the KNMI database spanning 10 years of measurements in Eindhoven.
The Eindhoven weather signature seems to match the most with the one from Oakland, CA.
So, when addressing the characteristic signatures given in the manual the signatures from
Oakland, CA to would be the best set to be used. But still the weather signatures do not
form a perfect match and so the exact calibration changes performed by using the Oakland
characteristic signatures will be slightly different.
When it appears to be necessary for proper calculation, it can be chosen to adapt the
characteristic signatures for the specific weather situation in Eindhoven.
3.5.4 Calibration evaluation and statistics
In order to evaluate the quality of calibration of the simulations 1) several metrices can be
used. The two metrices suggested in the calibration manual, and also available in ABCAT, are
the Root Mean Square Error (RMSE) and the Mean Bias Error (MBE).
The RMSE is defined as:
The RMSE is a good measure of the overall magnitude of the deviation. It represents the size
of errors and the amount of scatter, but it gives no information about the overall bias in the
data. If large errors are distributed both above and below zero the RMSE would have a high
value. Similarly if all the errors would be positive, the RMSE would have the same value. The
RMSE is stated as being an useful metric of how ‘good’ the simulation results are in
comparison with the measured results. The manual also says that in general a RMSE
between 5 and 10% of the mean value of energy consumption is a very respectable result. It
will be difficult to achieve a lower RMSE in a regular building energy use calibration process.
41
The MBE is defines as:
In contrast with the RMSE, for MBE the positive and negative errors will cancel each other
out. The MBE is an overall measure of how biased the data is and is also a good indicator of
how much error will likely be introduced in the annual energy consumption estimates, since
here positive and negative errors are cancelled out as well.
A simulation with a small RMSE, but with significantly larger MBE, indicates a possible error
in simulation inputs. The residual is not significantly large but it is constantly either positive
or negative. The simulations can usually be improved by altering the responsible parameter
for a specific amount.
A simulation with a large RMSE, but with a small MBE, might have no errors in input
parameters, but the building performance is likely to show some unexpected, unmodeled
behavior that is difficult to simulate.
Minimizing both the RMSE and MBE is essential if a calibrated simulation is to be used as a
baseline for estimation of energy savings or fault detection and diagnosis.
The basic calibration process will start out by carefully monitoring the RMSE for both cooling
and heating after each input parameter alteration carried out. Also the mean RMSE is
important because often a change to inputs will increase the heating RMSE while decreasing
the cooling RMSE, or the other way around. If the mean RMSE decreases, it was a useful
alteration after all. The residuals should be scattered around zero and the calibration
signature has to be flat and should show no trend with the outside air temperature (Claridge
et al., 2003) in order to come to an accurate calibration result.
In the evaluation process (step 4) in the calibration overview) given pairs of heating and
cooling calibration signatures are compared to the characteristic signature pairs, especially
paying attention to characteristic intersects, slopes and bulges. It also has a high priority to
pick a characteristic signature that results in improvement of both the HW as CHW results.
Input parameters should be identified that, when changed, are most likely to minimize the
residuals over the targeted range of outside air temperature. If multiple pairs of
characteristic signatures have similar shapes, it has to be estimated which one is most likely
to be inaccurate in the initial simulation.
If the calibration signatures do not show a strong resemblance with any of the characteristic
signatures, take an input/signature that will counter the residual with the highest magnitude
or one that will remove any strong irregular shapes in one of the calibration signatures.
The amount of change should be estimated by comparing the magnitudes of the normalized
residual and the normalized result change in the characteristic signature.
Parameter alteration (step 5) is followed by new simulations (step 1), new calibration
signatures (step 2) and the evaluation (step 4) of the new RMSE, residuals and cooling and
heating calibration signatures. Step 1, 2, 4 and 5 (in the calibration overview) have to be
repeated until the total RMSE is minimal and the calibration results are satisfactory.
42
3.5.5
Evaluation of the supplied characteristic signatures
Four HVAC systems are provided:




SDCV, single-duct constant-air-volume
SDVAV, single-duct variable-air-volume
DDCV, dual-duct constant-air-volume
DDVAV, dual-duct variable-air-volume
The HVAC system in the case study building is of the SDCV type. The air flow produced by
the air handling unit is constant and the amount of heating and cooling of the air stream is
constantly adapted to the user’s demand. Only characteristic signatures of the SDCV system
type set are addressed in this study.
The following parameters can be found in the characteristic signature libraries:











Cold deck temperature
Hot deck temperature (DD systems)
Supply air flow rate (CV systems)
Minimum air flow rate (VAV systems)
Floor area
Preheat temperature
Internal gains
Outside air flow rate
Room temperature
Envelope U-value
Economizer
These parameters have been chosen by the authors because they are frequently containing
errors causing inaccurate simulations (Claridge et al., 2003). In order to find out the
significance of these given parameters for the case study project the Characteristic
signatures supplied with the manual are compared with the creation of new signatures:
1. The Eindhoven weather characteristics do not exactly match the given location
weather signatures, which is one incentive to choose for making new ones.
2. The given characteristic signatures include a lot of parameters that are either absent
in the set of ABCAT input parameters or later on appear to be very insignificant
parameters with little influence on the simulation results. Examples are: Hot deck
temperature (N/A for SDCV systems), Minimum air flow rate (N/A for SDCV
systems), Preheat temperature (N/A) and Economizer parameters (N/A).
3. ABCAT has a lot of input parameters that are not covered in the signature library.
Parameters like Heating & Cooling (+ setback) set-points, Wall and window areas
and U-values, Heating and Cooling curve set-points, Various Air Flow rates, Thermal
Mass and Area per occupant are likely to be significant input values. The complete
43
list with ABCAT inputs is covered elsewhere in the report. This availability of plenty
of additional input parameters is another good reason to create new signatures.
4. General characteristic signatures are not necessarily valid and precise for any kind of
building and simulation program. Custom made signatures for a specific situation
are expected to be better than generic signatures.
Because of these reasons, it was chosen to create a new set of characteristic signatures for
the specific building for the locations Eindhoven, Netherlands. How the signatures are made
can be seen in the section about characteristic signatures earlier on. The produced
characteristic signatures can be found in appendix D.
5) Input parameters to adjust
A selection has been made of parameters that:
- Make sense to change
- Are not strictly defined for the case study building. Certain obvious and very specific
parameters such as: system-type, solar irradiation, outside temperatures, absence
of economizer and the measured electric energy use are strictly defined and not
suitable for alteration
- Actually do have an impact on the simulated energy uses. Parameters that need a
large, unrealistic alteration to achieve significant changes are discarded
Area and mass:
- Floor Area: Is not present in the supplied library but clearly has a significant impact
on heating and cooling energy consumption.
- Area per Occupant: The increase of area per occupant brings very interesting
changes in the form of a strong negatively sloped profile. Slight increase of the area
per occupant decreases heating and cooling for low temperatures and increase
them for high temperatures.
- Thermal Mass: An increase does not change anything. A decrease has a positive
influence on the cooling demand.
AHU volumetric flow rates:
- Exterior Zone Air Flow
- Interior zone Air Flow
- Exterior Zone Outside Air Flow
- Interior Zone Outside Air Flow
- Exterior Zone Minimum Air Flow
- Interior Zone Minimum Air Flow
All of these inputs have an influence on the heating and cooling energy consumption and are
therefore added to the set of characteristic signatures.
Envelope:
Wall area and window area: These parameters need large alterations in order to achieve
significant changes to the energy use. Large increase of these areas produce a small cooling
44
increase for low temperatures and a small heating decrease for high temperatures. Because
such large alterations are required it might be better not to use these parameters.
Wall U-value and window U-value: A decrease of the U values results in a decrease of
cooling and an increase of heating requirement, both with a positive slope. This makes it an
interesting profile for simulation manipulation.
Heating and cooling setpoints:
These are interpreted as the temperatures at which the hot and cold circuits are maintained.
Water from these circuits will in turn be used to provide the heating and cooling coils in the
air handling units. The heating setpoint only influences the heating consumption for low
outside temperatures. The cooling setpoint does influence both the heating as the cooling
energy uses.
30
25
20
15
10
5
0
Heating set point (°C)
Cooling set point (°C)
Heating and cooling curves:
In ABCAT specified as ‘Coil set-point temperature schedules’.
0
30
25
20
15
10
5
0
0
20
25
30
Outside temperature (°C)
20
25
30
Outside temperature (°C)
Figure 32: The heating and cooling curves of the case-study Air Handling Units (AHUs), which are important
parameters for the ABCAT calibration procedure.
A low outside temperatures require less cooling, hence the setpoint for cooling has a higher
value for low outside temperatures and a lower setpoint (more cooling) for higher
temperatures. Two of these setpoints are used in combination with linear behavior between
them as can be seen in the cooling cure in figure 32. Similarly more heating is required for
low outside temperature and less heating is required for high temperatures, resulting in the
heating curve shown above.
Alteration of both the outside temperature markers and the corresponding control set
points result in significant and a wide variety of changes to the simulated energy uses and is
an important addition to the signature set from literature. The corresponding characteristic
signatures can be found in appendix E.
3.5.6 Definition of calibration period and test period
Before calibration can be started it is important to make a substantiated decision on which
time period is to be used for calibration purposes and which period will be the target test
period for the case-study system. A calibration period must show uniform, consistent
behavior and the time range should be sufficient. A test period has less requirements but it
is advantageous if there is a period with changes to the system, for which both the time and
the description of the change is documented.
45
Two periods of measurements of uniform HVAC system operation are available:
 1 August – 30 November 2011 (before the HVAC control improvement)
 1 January 2012  still running (after the HVAC control improvement)
The first period is not suitable because the system has not been optimized yet, which greatly
decreases the value of simulating this period with inferior functioning. The second period is
much shorter, which can be problematic for calibration but here the system is optimized and
will yield much more useful results for building optimization and FDD. It is chosen to use the
period of the 1st of January to the 1st of April 2012 for calibration of the ABCAT model.
During the month December several modifications and optimizations have been carried out
on the HVAC system. The modifications have been properly documented. This period is
suitable for testing the calibrated model on its fault detection abilities.
Figure 33: Indication of different periods within the total measurement period, respectively:
1)
Period of initial measurements, pointed out to represent suboptimal system behavior
2)
Period with major system changes and improvements making it a good test period
3)
Calibration period, representing continuous, optimized climate system behavior
The measured quantities (mass flow and heat flow in the induction circuit) are not important in this figure. It is
the characteristics of the behavior shown (chaotic with much deviations or stable and consistent) which is
important in this figure.
46
3.5.7 Application of the calibration process on the case-study building
Trough the analysis of strange calibration results caused by certain parameter alterations
some incorrect relations in the interface-model connection (section 5.1) were found and
corrected before calibration procedures could start. The calibration process is initiated
according to the step-by-step calibration overview presented in 3.5.3. The firs ABCAT
simulations are applied on the calibration period with the best estimates of input data and
settings, yielding the following results:
ABCAT simulation results using best estimates for input parameters:
a
b
c
d
Figure 34: ABCAT simulation results next to measured data during the calibration period and for simulations
using the best estimates of building parameters.
a)
CHW measurement and simulation as function of time
b)
HW measurement and simulation as function of time
c)
CHW measurement and simulation as function of ambient temperature
d)
HW measurement and simulation as function of ambient temperature
Observations:
-
-
34a and c: Overestimation of the cooling energy consumption. ABCAT does not
‘understand’ the cooling should be off for outside temperatures below 5°C. This can
be corrected by applying a manual winter cooling block in the ABCAT calibration
process.
34b: The simulations show a strong weekend dependency. For weekends the model
overestimates the energy consumption. Instead of higher energy use in weekends,
this should be lower than for working days.
47
Calibration signature generated for the best estimates / baseline simulation case:
For the base case simulation with best estimates the calibration signatures are generated in
an extra ABCAT output sheet especially designed for the calibration process of this project.
The calculation of a calibration signature is treated in 3.5.3. This calibration signature
represents the deviations between simulations and measurements in the current state of
the ABCAT model as can be seen in figure 35 and is used for the selection of further
calibration steps.
a
b
c
d
Figure 35: ABCAT calibration signature showing simulation - measurement residuals related to the outside
temperature for the ‘best estimates’ model situation. RMSE values are added for model accuracy evaluation.
These calibration signatures are the baseline for the characteristic signature calibration approach.
a)
CHW simulation-measurement residuals for each individual measurement point
b)
CHW calibration signature, including normalized and polyfit representation
c)
HW simulation-measurement residuals for each individual measurement point
d)
HW calibration signature, including normalized and polyfit representation
In the baseline simulation some specific, large deviations between simulations and
measurements stand out (as is seen in the observations of figure 34). These are the Winter
Block issue and the Weekend Behavior issue. These problems are not caused by wrong
estimates and easily solvable by calibration but are more related to flaws or shortcomings in
the ABCAT model. A lot of improvements are expected from the application of winter block
and weekend fix before further application of the calibration method. The order of
improvements/calibration steps is as follows:
48
Initial 'Best
Estimates'
simulation
2) Application
of the
calibration
method
1) Correction
obvious flaws in
model
Calibrated
model
Figure 36: The order of steps taken in the calibration process
1)
Correction for model shortcomings
Winter block: The case-study building is outfitted with new control software which includes
a blockade for cooling in winter and heating in summer, as further explained in 2.6.2. For
outside temperatures below 5oC the cooling is shut down completely. This is some behavior
that is not present in the ABCAT building models and it is logical that this is not simulated
correctly. An easy way to fix this is to add a manual Winter Block. The manual Winter Block is
applied by changing the values in the ABCAT output cells by a simple filter loop: IF outside
temperature < 5  simulated value CHW consumption = 0
The manual Winter Block works with satisfying results, as can be seen in figure 37. Because
of practical reasons (every simulation run removes the filter again, and the filter does
overrule the exiting simulation results) this solution will be ordered to be the last applied
step of processing.
Figure 37: Application of the winter block for cooling, related to time.
Weekend Fix: To correct the overestimation of energy consumption in weekend, several
occupancy and HVAC operation schedules are altered to find a parameter which can correct
this behavior. The weekend fix is an adjustment that is related to the weekday-weekend
behavior schedules and is in no way compatible with the calibration signatures and
characteristic signatures methods(temperature related). Schedule alteration has to be
applied separately from the calibrations signatures method to prevent negative influences.
The best correction for weekend behavior was found by decreasing the HVAC Operation
Fractions for weekends from 1 to 0.5.
49
Figure 38: Application of corrections of the weekend schedule and behavior shown on the HW energy
consumption figure, related to time.
2)
Calibration using the characteristic signatures method
Making use of the calibration signatures method calibration is carried out to find the best
possible match between measurements and simulations. The calibration signature above
(figure 38) was used in combination with the characteristic signatures from appendix E. The
order of calibration steps is based on the best shape matches of the signatures:



The internal gains factor was optimized to 0.6. This gave the best tradeoff of
improvements to both heating and cooling simulation.
The Air flow (OA, exterior zone) decrease from 0.1cfm/ft2 to 0.03cfm/ft2 was a
major improvement for the cooling simulations.
In order to increase the heating simulation results the heating set-point was
increased from 21oC to 24oC which gave the best matching results.
In table 5 the Root Mean Square Error for the cooling, heating and total simulation accuracy
are presented for the chosen steps in the calibration process. The RMSE is a performance
indicator for the quality of calibration results. The average values of measured cooling and
heating energy consumption are: CHW about 3 MMBtu/day and HW about 14 MMBtu/day.
As a percentage of the mean consumption values the final RMSE values are respectively 50%
and 35% resulting in a total relative RMSE of 43%. According to the calibration manual a
RMSE between 5 and 10% of the mean value of energy consumption is a very respectable
result for a FDD oriented building model. The use of RMSE is further explained in 3.5.4.
Table 5: Showing the resulting RMSE after several steps in the calibration process. The RMSE indicates the
quality of calibration, lower RMSE indicates a better result.
Calibration state
Initial situation
Internal gains factor correction
Air flow correction
Heating set-point correction
Winter block & Weekend fix
Cooling RMSE
1
[MMBTU/day ]
10.71 (360%)
10.66 (360%)
3.29 (110%)
3.29 (110%)
1.5 (50%)
1
Heating RMSE
[MMBTU/day]
4.58 (33%)
4.48 (33%)
7.70 (55%)
5.51 (40%)
4.9 (35%)
Total RMSE
[MMBTU/day]
7.64 (200%)
7.60 (200%)
5.50 (80%)
4.39 (70%)
3.3 (43%)
Million British Thermal Units (1 BTU = 1,055.06 joules) The unit is not important though, the results
are treated in a relative way.
50
By the combination of the two simulation improving strategies mentioned above the best
simulation calibration result is obtained. The best results are presented in the results section
(Chapter 4).
3.5.8




Remaining calibration problems and challenges
Nearly all the parameter changes influence both the heating and cooling energy
consumption. Improving one of them often results in the other one getting
significantly worse. The ideal combination of parameter changes to have them both
optimized has not been found.
As can be seen in figure 39a (emphasized with red lines) the produced HW energy
consumption simulations all appear to be very flat figures. Correct simulations
would show more sloped figures, caused by the outside temperature dependence of
the heating demand. This temperature dependence sloped relation with the outside
temperature is not present.
There is an unexpected and unexplained boundary at 55°F outside temperature as
can be seen in figure 39a (emphasized with the blue vertical line). The simulation
results for heating energy use are completely different on the two sides of this
boundary. This phenomenon is expected to be related to the applied physical model
but no explanation of this phenomenon is found. The 55°F value is NOT present as
an ABCAT input and did not change during the calibration process and alteration of
many of the ABCAT input parameters.
Sometimes with a small alteration of a parameter, ABCAT suddenly comes up with
an extreme energy use estimation shoot out (figure 39b) that cannot be explained.
All the environment data inputs (electricity use, temperatures and humidity’s) of the
days around these shoot outs are completely in line with those from the days with
predicted shoot outs.
Figure 39: The following figures illustrate some of the mentioned problems. They are not from the same
simulation and should not be seen as being related in some way. ABCAT simulation figures giving examples of:
o
Absence of temperature dependence, the 55 F boundary and unexplained shoot-outs.
3.5.9 Conclusions on the Calibration process
Calibration insufficient as can be seen in the large deviations between measured and
simulated energy use during the calibration period and the high values for RMSE. The
calibration does not lead to respectable results by far. Calibration failure is assumed to be
caused by both ABCAT issues (prototype and unguaranteed compatibility) and unwanted
behavior of the HVAC systems in the case-study building.
51
52
4
Case-study results
4.1
Building heating and cooling energy consumption
Figure 40: Showing a bar plot representation of the daily energy use for heating and cooling over time. The
average outside temperature is added to emphasize the temperature dependency of the energy
consumptions.
Through the measurement setup applied on the case-study building and the proper
processing of individual measurements into building total values, the following daily heating
and cooling energy consumption quantities are obtained. The measurements and calculated
results are validated (Appendix G) and are expected to provide a close representation of the
real energy consumptions in the building. The accuracy is not perfect but assumed high
enough for building level FDD application.
53
4.2
ABCAT calibration
As already mentioned in chapter 3.5.8, the calibration of ABCAT was not successful. Making
use of the calibration signatures method, figure 41 shows the best measurement –
simulation match that could be achieved. Based on visual comparison of the calibration and
characteristic signatures there still seems to be room for parameter alterations which
improve the measurement – simulation match. In practice though, no more alterations have
been found which improve both the heating and cooling energy use simulations
simultaneously. Improvements to CHW results are accompanied by decreasing
correspondence for HW results and vice versa.
Figure 41: ABCAT output figures for simulations with most accurate calibration results. Because of the poor
correlation between measurements and simulations this calibrated model not suitable for FDD purposes.
Observations:


41a &c: Due to the manually applied Winter Block the cooling for low outside
temperature shows a satisfactory match. The small differences are explained by the
daily averages that ABCAT uses. If the average outside temperature is < 5oC the
cooling for the whole day will be 0. In reality, on cold days (mostly < 5oC ) for the
majority of hours during the day there will be no cooling, but for the hours during
the day that the temperature > 5oC there can be some cooling. So small amounts of
cooling can still be measured.
By the calibration method it was possible to have the cooling predictions in the
same range as the measurements, as can be seen in the figure. However, the
separate measurement and simulation data points do not properly match though
due to improper simulation results. The heating results shows even less correlation.
54
4.3
Fault detection results
As previously stated, no accurate simulations of the building energy consumption have been
achieved. The fault detection process, making use of measurement-simulation comparison,
is strongly dependent on the quality of simulation of the target system. Consequently, the
intended level of fault detection is not possible with this poor simulation quality.
However, it has been investigated to which extend it is possible to detect certain faulty
behavior with these poor results. As can be seen in figure 42 there are certain large
deviations that even stand out to the overall residual that is present.
Figure 42: ABCAT results with the poorly calibrated model for the 'test period'. Although calibration is
considered insufficiently accurate for FDD purposes it is possible to observe and analyze some of the large and
obvious deviations in these figures.
Observations and provisional conclusions:



42a&c: The measured cooling consumption during warm days is significantly higher
than simulated. Even though the simulation quality is poor and the deviations can
just as well be caused by wrong simulations, observation of these figures can be an
incentive to take another look at cooling set-points in the building for optimization
possibilities.
42b&d: A large deviation between simulated and measured heating is observed for
higher outside temperatures. The simulated values are rather low and unrealistic.
The measurements show the actual behavior of the system.
The simulation quality is indeed too low to detect faults in the system behavior.
Observed deviations are due to simulation flaws and not to anomalies in HVAC
system operation.
55
4.4
Diagnosis results
Because simulation quality was insufficient , the ‘Expert rule’ method could not be used. No
conclusions on the capabilities of this method could be drawn.
Although the simulation and fault detection using ABCAT FDD functionalities is proven to be
unsuccessful there are other ways to diagnose and locate faults in the system behavior.
Analysis of measurements carried out in subsystems or on individual components of the
building HVAC system, without the application of any simulations can also yield interesting
observations.
Measurements on some well chosen, sub-system level locations can give valuable
information on the performance of this specific subsystem. Measured anomalies in behavior
can be directly related to failure or unwanted behavior of the subsystem. An expert is
required to analyze the measurements in order to correctly identify the fault.
Analysis of component level measurements is not so strong for detection and identification
purposes. There are a large number of individual measurements to take into account in
contrast with the top down approach, in which faults are detected by analysis if total energy
consumption only, which supplies a much better overview on the building climate system
status. Individual component measurements also show much more fluctuations than the
total energy use, making the identification more difficult. On the other hand will component
level analysis yield direct isolation possibilities. If a fault is detected then it is directly known
in which component this is caused.
Although it was not a direct goal or intention for this project, possibilities for the mentioned
diagnosis methods occurred. As part of the building energy performance assessment several
subsystem measurements were observed during regular use of the BMS interface and during
the data processing applications with Matlab. From these subsystem measurements various
conclusions are drawn which can are definitely interesting applications of diagnosis without
use of simulations software.
Examples (treated in more detail in chapter 2.6.3: building energy performance after
improvements):



Temperature measurement of supply water, return water and return water after
buffer tank outlet will give insight on the buffer tank layering capabilities.
Analysis of the rate of temperature change in sections of HW or CHW piping after
being (temporarily) shut down yields information on possible leakage between the
two.
By having a control technician (expert) analyze the control schemes present in the
BMS various control faults will definitely be found:
o There is no winter/summer block resulting in simultaneous heating/cooling
o There is no heat pump cycle implemented
o The buffer tank setup does not contain the essential sensors to apply proper
buffer tank layering
56
5
Discussion
5.1
ABCAT assessment
For the consideration of the use of ABCAT for current and future FDD applications by TU/e
and Worksphere, the experiences in the use and applicability of ABCAT are documented.
Is ABCAT any good as simulation program?
The calibration process of ABCAT was focused on a time period which is assumed to
represent a correctly functioning building, also referred to as the baseline period. For a
correctly functioning building the measurements and simulations must show a strong
correlation. If not, there is not a valid basis to apply an FDD method on. Past projects show
that ABCAT is able to produce accurate simulation results of various buildings and systems.
In this case-study it was not possible to reproduce this level of simulation accuracy.
The quality of simulation depends on the compatibility between model and system.
Although ABCAT is expected to be a good simulation program it didn’t turn out to be
appropriate for the case-study building because of compatibility issues and
underperformance of the building.
Is ABCAT simulating the case-study building behavior correctly?
ABCAT is simulating (sub-) systems as they should be functioning while the actual systems
are not functioning as intended. Mismatch between results of the calibrated model and
actual measurements are caused by both faults in building HVAC system and general
underperformance and shortcomings of ABCAT prototype and compatibility issues.
In the starting phase of this graduation project it was assumed that ABCAT would be
compatible with the case-study system. Although ABCAT was mostly used to simulate US
buildings in the past, there is also a good example of successful simulation of the Vertigo
building in the Netherlands (Peitsman et al., 2010). The differences between US and EU
building styles should be kept in mind when using ABCAT and testing its compatibility with
the case-study system. In the ABCAT documentation some requirements for the target HVAC
system are given. There is no direct exclusion of the systems in the case-study building but
also not a direct guarantee that it would work. In practice, calibration of ABCAT turned out
to be unsuccessful, which is an indication for possible compatibility issues after all.
ABCAT interface and ease of use
The interface and the documentation coming with ABCAT are not complete and could be
more detailed on various aspects of use. A lot of inputs and steps to take were unclear in the
first sessions using ABCAT, leaving multiple obstacles which made it a time consuming
process just to get to the completion of parameter input and realization of simulations.
ABCAT is a tool which is in development and the version used in this study is still a
prototype. This explains the encountered unclarities and obstacles. The current version is
not made for retail use and there is no customer support.
57
Additional complications with the interface presented themselves in the form of incorrect
connections between the interface and the physical model. For example the alteration of
parameters involving weekend behavior resulted in changes of the simulations for working
days and vice versa. Plenty more of these unexpected mismatches in the interface were
found by trial and error in the use of ABCAT resulting in a lot of unnecessary hours of delay.
ABCAT simulation quality
Another thing is to validate and assess the correctness of ABCATs energy use predictions.
ABCAT appears to be very reliant on input parameters. During the calibration process it is
found out how sensitive the results are to small parameter alterations. Building parameters
are often estimates, or based on design values which do not exactly match the real-life
parameters. Consequently the calibration becomes a rather difficult and instable process.
There is no good balance in the transition from the initial simulations to the calibration
process, the physics-based model seems not able to produce good absolute results and
results rely heavily on the calibration process and the manipulations of parameters to get to
the desired result.
Adaptation and expansion of the ABCAT models
ABCAT has no options for summer and winter block in its physical model. It is not expected
to be able to predict the very sharp threshold of shutting down the cooling for outside
temperatures below 5°C, which is happening in the actual building. By manually adding a
script for the appliance of this winter block you are actually adapting the existing ABCAT
with models for average HVAC systems to fit the specific case-study system. Besides the
winter block, which absence was very clear in the ABCAT simulation results, there are
definitely more of these specific behaviors of the case-study system that are not
implemented in the ABCAT models and thus influencing the calibration results.
Incompatibility between ABCAT physical models and the actual behavior of the target HVAC
systems is very likely one of the most important causes of the failure of accurate simulation.
In the end, not only for this projects ABCAT flaws are noted and recommendations for
improvements are done. (Zeiler & van der Velden, 2011) also states that ABCAT is a very
promising tool, with good FDD results, but that it requires additional development from a
prototype into a real product.
Possibilities for generic calibration
One of the questions we had on the applicability of ABCAT is about its flexibility: When
applying ABCAT on a next building, is FDD possible without a second calibration procedure?
Generic calibration is not possible, calibration is carried out by alteration of building inputs.
For a second building most of the inputs are different so the previous calibration efforts
cannot be transferred to this new building in any way.
58
5.2
Building energy performance assessment
After the findings of poor building performance in chapter 2.6 it was chosen to look at the
circumstances around this building performance issue from a higher perspective. It is
investigated how certain steps in the design, building and exploitation process have taken
place and where things went wrong. Also is the development and delivery process for the
case-study building compared to the building sector in general.
By means of interviews with technicians and engineers participating in the construction,
delivery and exploitation of the case-study building (concerning the questions presented
below) a better view on the procedures has been formed. Moreover plenty of conversations
and discussions with colleagues at Worksphere (Maintenance engineers and energy
consultants) have taken place which also supplied much insight in these affairs.
Why was the building never commissioned?
Commissioning is never included in the price, a detailed commissioning process is expensive.
For the building owner/client this has no high priority, he will not be the one paying the
energy bill. A building realized in a fast and cheap way has much more value to him. If all the
climate systems work, somehow he is satisfied already.
Why does a building services contractor like Worksphere accept a building like this?
The purchase and acceptance of a newly rented office space are carried out by people from
the organizational/financial side of the company. There is no knowhow on climate systems
and their performance. The technicians and people with knowledge of climate systems are
hardly ever involved in this process so performance issues are not taken into account.
Why was assumed that the building and its systems were working correctly?
Because there was no knowhow on building performance assessment and issues some
wrong assumptions were made. The first logical thought everyone has when encountered
with a brand new building is that it would function quite well. It would make sense that
every newly delivered building has had some kind of commissioning and performance
assessment. Apparently these things just don’t happen. A building and its systems are
constructed and put to use and no one checks it. Only after comfort issues and months later
someone will come and take a look at the random settings that were applied to an
unchecked/tested system.
In the world of other consumer products (not being buildings) the inspection of newly
produced goods is a routine that is hardly ever skipped. If a new product is bought the
quality and initial performance is usually pretty good and this performance only declines
throughout the time of use. In general the consumers are very critical and demanding. For
buildings this is apparently not the case. Some of the engineers at Worksphere were new
and unknowing towards the issues around building delivery and underperformance of
climate systems just like me. Others know this phenomenon already for years, it’s called the
‘throw it over the hedge’ mentality.
59
Building companies, and also the process of constructing and exploiting buildings mostly has
two separate sides. The design and construction side, and the exploitation/maintenance
side. When a building is finished the constructors pack and leave, throw the product over
the hedge and don’t look back. There is hardly ever any information or instructions left
behind for the people who start to use and maintain the building.
The building management and maintenance people receive the newly constructed building
without any information of its status and probably just assume it is functioning well. They
don’t receive information about how the system is configured exactly and whether it has
been properly tested on energy performance or not. Possibly it is assumed that the people
who constructed the building and its climate systems actually did some testing/fine-tuning
work but it just didn’t happen. Only after some time (months) of experience with the new,
not-well-understood, building they start to notice and realize the flaws and malfunctions
present.
Moreover: Configuration of the BMS control settings are often executed without being
thought over and by people with a lack of knowledge of the target building. When comfort
issues present themselves set-points are altered to solve the short-term complaints. Hereby
the energy use of the systems is not taken into account, which makes that improvements of
comfort are often accompanied by a strong decrease of energy efficiency.
Why are poorly performing climate systems built and delivered that way?
This issue also has a very important financial side. Large building construction projects
sometimes tend to exceed budget. In the later stages of construction (where buildings
systems get installed) it appears that money is running out. This can lead to various
presumed consequences:




Installment cheaper systems than intended in the design
Leaving out expensive sustainable sources and applications
Time pressures for the constructors: the climate installation is placed then there is
not time and money for inspection and fine-tuning of the systems
A real commissioning/testing phase of the new building being discarded
For project managers, an achievement oriented approach is dominating. Often projects
should be finished as fast and as cheap as possible. Have the constructors place everything
as fast as possible, save in construction time and budget to end up with a higher margin. In
general the systems are doing what they should do without malfunction, but will not
function very effectively. From a project management perspective these are good results
and they will not directly be accounted for building energy performance.
Even if some people with knowledge about the functioning of building systems do know
about or suspect improper performance of the systems, there is in most cases not much
incentive to do something about it. It will involve additional costs (even though the finetuning and improvements of systems save a lot more money) so it is difficult to convince the
management of taking action and supply budget for improvement purposes.
60
(Elkhuizen & Rooijakkers, 2008) gives a good indication of the various causes of
underperforming buildings. In general 85% of the problems is caused by improper use and
management of the building. Only a small share (15%) of the problems is related to faults in
the design and construction phase. In practice it is observed that in the BMS various
components are not properly controlled and set-points are not tuned to the actual physical
properties of the building and the actual use of the building.
Project management will sometimes also decide for savings and budget cuts on sustainable
energy applications and other HVAC equipment. Cheaper components are chosen to achieve
higher margins or to be able to meet budget requirements. The cheaper solution will also
work but the energy performance over the subsequent years is likely to be significantly
lower. Sustainable applications are important for the process of energy savings in buildings
and can also be beneficial in costs for building owners over a longer time period. Because of
the high capital costs they are often cut from the initial building design.
Who built/assembled the HVAC systems in the Worksphere office building and how was
their cooperation?
-
The owner and client of the building is Van Schijndel Vastgoed
The building is rented and occupied by Strukton Worksphere and Centric
Van Schijndel Bouwgroep and Strukton Bouw realized the construction of the
building
Strukton Worksphere – Business Unit Projects was in the role of subcontractor
responsible for the building installations
There was poor communication and documentation about the work carried out, state of the
systems at the time of transfer between parties and the performance of the delivered
system. In case the fine-tuning and testing phase of the installment of equipment is skipped
for some reason it
Why was such a poorly functioning system delivered?
Presumed causes for the bad state of equipment and configurations for newly constructed
buildings entering the exploitation phase:




Lots of contributing parties and no clear, overall responsible party
Poor communication and transfer of work between constructing parties and
maintaining parties
No ‘hours’ available for proper testing and revision of the installed machinery
Budget cuts in equipment purchase
Often there is only time available (as in hours available to spend on the project according to
the budget) for basic placement and connection of equipment. There is a general lack of
time and money for testing, tuning and revision of the installed equipment.
61
We know that some previously undiscovered energy problems were present in the casestudy building. Are these things that occur in more buildings?
In many cases, just like with the current test-case building, there is no good insight in the
functioning of the climate systems is a building. There is a large demand for measurements
and visualization of the energy flows present in the building systems.
For the case-study building, a clear overview of the total amounts of HW and CHW produced
and the division over the different subsystems in the building would be of great help: The
amount of energy produced by heat pumps, the amount of energy coming from the heat
exchangers, from excessive engine heat and thermal energy produced by a hot water boiler
are important to know. Moreover it is interesting to know which fraction of the gas
consumed is used for office heating and which fraction is used in the large, less insulated
magazine, which is heated by a single hot water boiler. In the current situation these specific
flows are not measured. More detail on these individual energy flows will also greatly
improve the fault detection and localization process.
There is a general lack of knowledge of the building energy performance state and a lot of
improvements are possible in both the technical and the organizational aspects of
monitoring and commissioning.
From talks with various built environment oriented engineers and consultants it seems that
the issues presented in this chapter are occurring very often in all kinds of building projects.
It is hard to quantify the real extend of these inefficient and unwanted proceedings
concerning the construction and delivery of buildings.
5.3
Expert view versus automation
In almost every current commissioning and FDD application, experts are used for manual
analysis and conclusions. Because of shortage and rising costs for the use of experts there is
a large need for automation of this process, as stated by (Zeiler & van der Velden, 2011). The
processing of large data amounts, as well as the modeling and simulation of complete
buildings are still complex and expensive methods. New technology is required to achieve
better results and reduce the costs.
One of the advantages of manual assessment by experts compared to automation is that
experienced maintenance engineers, energy consultants and other similar professionals can
accurately assess the processes in a specific building case and can also foresee problems
occurring in other aspects of building performance if actions are taken. If this is to be
automated the software must be able to correctly combine different aspects of performance
which is currently still a challenge. It is agreed upon that automation and simulation can aid
the experts in various ways: ‘Powerful analytics that add “intelligence” to existing building
infrastructure have the potential to transform the way in which companies manage energy
across their real estate portfolio. Also building engineers can be empowered to take a more
targeted, data-driven approach to their work while automation improves their productivity.
Substantial cost savings can be achieved with relatively low capital investments”. (Kofmehl,
Levine, Falco, & Schmidt, 2011).
62
There is a difference though between automation as an aid and full automation of an
assessment process: When there is a model of the building in a simulation program, how do
you turn it into automated assessment? This will fully rely on the absolute quality of the
simulation program results because it has to be assumed that the results are correct.
Consequently, compatibility issues between the modeled behavior and the real behavior of
the building will result in an offset that indicates a dysfunctional building. But is this really
the case? Engineers will always stay involved for the validation of proper simulation and FDD
functionality of software.
Also in the comparison between manual and automatic assessment the costs – benefit
relation in both time and money should be taken into account. For some situations the
expert assessment can have its advantages: If the unassessed building is available to an
expert and the expert is free to make changes and analyze the results this is a big advantage
for the expert approach. The expert can develop improvements, implement them right away
and monitor and report the performance results and side effects of his actions in the
subsequent days. A model based approach would have to be developed from scratch, which
is costly and time consuming and is not in favor for this situation.
In case a model of the target building is already available in any practicable simulation
software this will save a lot of time and costs, which is a benefit for the automated
approach. Making a detailed model of a building from scratch is a time-consuming and
expensive task. Before actually starting this task consider the time required and the use of it.
Spending all this time is usually worth it if the model can be used multiple times for diverse
purposes. A one-time assessment is not always of enough importance to undergo such a
task. Other options might be more efficient.
Development of a standardization process for building modeling and FDD could be of great
help to overcome these problems. Standardization would mean the use of standard models,
parameters, algorithms and control strategies which greatly decrease the work that
different parties currently carry out individually.
63
64
6
Conclusions and recommendations
During this study the applicability of the ABCAT FDD methods on the case-study building as
well as the energy performance of the building itself has been assessed.
Building performance
In the building energy analysis process (chapter 2.6) it is pointed out that the building HVAC
system is not functioning as it should. Various improvements were carried out but still it is
not said that the building functions according design specifications. Still there are faults in
the machinery setup and operation, such as buffer tank short-circuit, HW-CHW circuit
leakage and improper heating and cooling set-points. We showed that the measured
building energy use is much higher than designed. In order to set-up a proper FDD system, a
properly functioning building is a necessity which must be confirmed by a commissioning
process, which did not happen for the case-study building.
Presumed reasons for building underperformance (as discussed in 5.2):




Budget cuts and time constraints during building and delivery
Poor communication and transfer of work between involved actors
Disinterest of building performance by owners and management
Overall absence of incentive and knowhow of energy performance assessment
Simulation and fault detection results
For the application of monitoring and FDD on the case-study building additional information,
not provided by the building management system, had to be collected. A capable
measurement setup is applied (chapter 2) and measurement data of sufficient quality for
building level FDD is acquired. On the other hand ABCAT calibration and simulation results
(3.5) are unsatisfactory. There is no good correlation found between the measured and the
simulated energy consumptions during the calibration period which is essential for further
FDD procedures. This does not mean that these imperfect simulations are useless. The fact
that large deviations between simulation and measurements are found are a clear indication
that something is wrong with the building operation and additional research is required. It
emphasized the need for actions on the climate system performance.
Causes of calibration mismatch
ABCAT is simulating (sub-) systems as they should be functioning while actual systems
are not functioning as intended. Mismatch between results of the calibrated model and
actual measurements are caused by:


Faults in building HVAC system and general underperformance (4.4)
Shortcomings of ABCAT prototype and compatibility issues (5.1)
Shortcomings and possible improvements of ABCAT:

ABCAT is a promising tool with good FDD results, but it requires additional
development from a prototype into a real product before it should be used any
65


further. More functionality is required for use on more diverse (European)
buildings so HVAC systems and compatibility can be guaranteed.
ABCAT requires the look of an experienced building engineer. The engineer has
to inspect output figures manually with the expert rule table in hand for
detection and isolation of problems. More automation and intelligence in the
software are expected to be a great improvement.
The inclusion of component level measurements of some significant variables to
the expert rules method, as well as cumulative figures of subsystem behavior,
could be of great value for isolation purposes.
Although the goal of simulation-based FDD has not been reached, several faults in HVAC
behavior are detected after all. Careful monitoring and detailed analysis of measurement
data by experts, without a simulation reference, has strong FDD possibilities as well.
Recommendations
The importance of the conditions and the testing environment necessary for successful
application of FDD were not fully known or greatly underestimated at the start of the
project. During the project much knowledge and understanding of the importance of these
conditions has been obtained. As a recommendation the most essential conditions for FDD
should be emphasized. Conditions for a good basis to build model-based FDD on when
choosing a case-study building are listed. The building must:





Have been properly commissioned, it would help when the proper documentation
of the commissioning would be available.
Have sufficient post-commissioning measured consumption data by which to define
the baseline situation and sufficient continuous measured data from that point on.
Have had a known significant degradation in energy performance that was detected
by for instance sensible changes in indoor thermal conditions. These known and
documented faults are important for testing purposes.
Have additional information as to the nature or cause of the degradation in energy
performance available to compare with the diagnostic results of FDD applications.
Not have experienced any major changes or retrofits during the period analyzed.
Changes to the setup have a strong negative influence on the continuity of the
process and the ability to model it.
Recommendations for further FDD use and development for Worksphere
FDD is an important development with a lot of potential for energy savings and comfort
improvements. Before it is fully applicable, additional development and testing is required.
The lessons we learned during this project are an important step for Worksphere in that
direction. For further FDD developments it is suggested to aim at:

Application of further FDD research on different buildings that are proven to be
functioning as they should. The knowhow of setting up a suitable monitoring
environment is earned during this graduation project. Application of ABCAT also
deserves extra attention. It has to be tested if ABCAT yields better results on a
different, better performing building (4.4).

Testing the applicability of other simulation software. Many other simulation
software is available, plenty of them are even for free. The main goal is to acquire
satisfactory simulation results. If valid simulation results are obtained with a
66
different program, it is even possible to apply the ABCAT detection and diagnosis
figures discussed in this report (3.3), which can be reproduced outside of ABCAT.

Application of simulation-free FDD, only making use of careful monitoring of the
climate system behavior. In this report certain component level experiments and
observations are mentioned (4.4.3) that aided in the detection of faults. These
measurements can be applied and monitored in other buildings as well. For
instance: buffer tank layering checkup, test-case for HW – CHW leakage by looking
at rates of temperature change and simultaneous heating and cooling checks. Much
more of these specific component level measurements and experiments are
possible. It is expected to be very beneficial to extend the number of these
experiments and further optimize them and put them into use for building
performance assessment.

Expansion of regular building control into more ‘intelligent’ building control.
Predicting functionalities could be beneficial for the efficiency of building climate
control. Use the expertise obtained with Matlab data management (2.5) and
acquisition of KNMI weather conditions (2.3) to include some prediction
functionality to a Building Management System:
o Low temperatures predicted?  Increase pre-heating in the morning
o High solar irradiation predicted or measured?  start cooling and
ventilation before the indoor temperature gets uncomfortably high
o Sunny afternoon predicted?  Stop heating the building in the morning
o Tomorrow a scheduled meeting?  Adjust settings for pre heating/cooling
of the meeting room
67
References
Andersson, T. & (2010). TA Link Manual. Current. Tour & Andersson.
Carrier. (2009). Technical Specifications Systems Strukton Worksphere Eindhoven.
Carrier.
Claridge, D. E., Bensouda, N., Lee, S. U., & Wei, G. (2003). Manual of procedures for
calibrating simulations of building systems.
Claridge, D. E., & Lin, G. (2009). Retrospective Testing of an Automated Building
Commissioning Analysis Tool ( ABCAT ).
Curtin, J. M. (2007). Development and testing of an Automated Building
Commissioing Analysis Tool (ABCAT). Simulation. Texas A&M University.
Daelmans, A. (2012). Possibilities energy neutral building: Worksphere Son.
EPA. (2012). Heating, Ventilation and Air-Conditioning (HVAC) Systems. United States
Environmental Protection Agency. Retrieved from
http://www.epa.gov/iaq/schooldesign/hvac.html
Elkhuizen, B., & Rooijakkers, E. (2008). Visie op ontwikkelingen
gebouwbeheersystemen. VV+, mei, 336-338.
GasEngineering. (2011). R 410 A specifications.
Gebhardt, N. (2011). Centrifugal fans belt driven.
Hissel, T. (2011). Pictures HVAC systems SWS Son.
Hissel, T. (2012). Monitoring and FDD in building HVAC systems. Research internship
Sustainable Energy Technology Master program. Eindhoven.
Howell, Coad, & Sauer. (2009). Principles of Heating Ventilation and Air Conditioning
(pp. 393-480).
Knebel, D. E. (1983). Simplified Energy Analysis Using the Modified Bin Method.
Atlanta: ASHRAE.
Kofmehl, A., Levine, A., Falco, G., & Schmidt, K. (2011). Energy-Smart Buildings.
Demontrating how information technology can cut energy use and costs of real
estate portfolios.
Meulman, G. (2011). Nieuwbout Kantoor Ekkersrijt, Regeltechnische Omschrijving.
Eindhoven.
68
Morisot, O., & Marchio, D. (1999). Fault Detection and Diagnosis on HVAC Variable
Air Volume system using Artificial Neural Networks. Proceedings IBPSA Building
Simulation.
Peitsman, H., Aker, K. van den, Claridge, D. E., & Bynum, J. (2010). Energyanalyse en
foutdiagnose Vertigo-gebouw TU/e. TVVL Magazine, 46-51.
Priva. (2011). Priva Top Control. Retrieved from
http://www.priva.ca/en/products/priva-top-control
Siemens. (2011). Symaro – innovative sensors , measurable quality innovative
measurement that pays off over the long term.
Trane. (2012). Pictures Induction Units. Retrieved from
http://myfactoryrep.com/InfoSheets/ROSEMEX/Induction_Units.aspx
Utiliteitsgebouwen, E. (2009). EPU Strukton Worksphere Son.
Van Kleef, S. (2011). Plan van Aanpak, Gebouw en Installatie Monitoring. Eindhoven.
Wei, G., Liu, M., & Claridge, D. E. (1998). Signatures of Heating and Cooling Energy
Consumption for Typical AHUs. Proceedings of the Eleventh Symposium on
Improving Building Systems in Hot and Humid Climates.
WiSensys. (2012). WiSensys ® Wireless Sensor WS-DLTc.
Zeiler, W., & van der Velden, J. A. J. (2011, October). Van Commissioning naar
Presatieborging. TVVL Magazine, 18-22.
69
Appendices
A
ABCAT
FDD
HVAC
PPP
BMS
HW
CHW
KNMI
AHU
NaN
PHP
Abbreviations
Automated Building Commissioning and Analysis Tool
Fault Detection and Diagnosis
Heating Ventilation and Air Conditioning
Public Private Partnership
Building Management System
Hot Water
Chilled Water
‘Koninklijk Nederlands Meteorologisch Instituut’
(Royal Dutch Meteorological Institute)
Air Handling Unit
Not a Number
PHP Hypertext Preprocessor
70
B
Detailed description of the ABCAT interface
ABCAT is an excel based program. The whole interface (input specification and output
numbers and figures) is inserted in the various sheets of the excel file. The physical model
behind de simulations is present in several visual basic macros and will not be visible or of
any use for the common ABCAT user.
The interface of ABCAT consists of the following sections:




Interface (time domains for calibration and testing, statistics, tool for diagnosis)
Data (inputs and outputs including: Temp, RH, CHW&HW energy use, Electricity use)
Input (building parameters)
Simulation results
Interface sheet (tools for calibration and time period selection)
On the interface tab the desired x-axis range of the ABCAT output figures can be altered.
After standard simulation the start date of the given data-set will be visible together with
the number of weeks available. By changing this start date and amount of weeks you can set
the figures to a period that is used as calibration period. This way outputs of other time
ranges are not interfering with the visual calibration process.
ABCAT produces certain output figures (in tab “Periods1&2”) especially for the comparison
of results of two separate time periods (the training period (correct behavior) and test
period). The time range for these two periods can also be specified in the interface tab.
Moreover ABCAT gives some basic statistic values corresponding to the time ranges
mentioned above. These statistics guide in the calibration and Diagnosis processes for
ABCAT.
Figure 43: Data range input and basic statistic output in the ABCAT interface
One of ABCAT’s detection methods is the cumulative error figure. This output and detection
method makes use of a “day in excess” threshold for fault detection. In the ‘Consecutive Day
Chart Excess Consumption Levels’ box this threshold can be defined and altered.
The interface tab presents one utility for the diagnosis (localization) process. In the
‘Diagnostic Summary Count’ table all the days of the simulation period are placed in one of
three categories. The different categories are separated into three daily average outside air
temperature ranges, Toa < Ts,sp (supply air temperature); Ts,sp < Toa < Te,sp (temperature the
economizer deactivates); Toa >Te,sp. For each outside air temperature range, the total days
where the simulated consumption (CHW and HW) is greater than, less then or within de
deviation range of the measured consumptions are counted and fill the table appropriately.
This table is the major source of information for the Expert rules diagnostic method, which
will be presented later on in the report.
71
Figure 44: Diagnostic Summary Count table, to use with the Expert rule method
Besides the previously mentioned contents the interface sheet covers the following, less
interesting inputs: ‘costs per energy unit’, ‘consumption totals’, ‘alarm parameters’ and
‘input and output data file locations’.
Data Sheet (time-dependent in- and outputs)
This sheet has two versions, the ‘Imperial unit’ version and ‘SI’ version. All processes in
ABCAT make use of imperial units but the SI variant is there as extra information for SI users.
The data in the SI tab is linked to the imperial tab and shows the SI representation of all the
data in there. This does not work the other way around.
This sheet stores the ambient and indoor conditions, measured and simulated consumption
values as well as the results of several calculations performed with this data. For the indoor
temperature, indoor dewpoint-temperature and electricity use this tabs makes a distinction
in Pre-occupied period average value, Occupied period average value and Post-occupied
period average value. This distinction is important for the building occupation related factors
in the simulation process.
Columns A thru O on this sheet are configured as follows:
 A-C: Date, Average Daily Outside Air Temperature, Average Daily Dew Point
Temperature (or Relative Humidity)
 D-F: Measured Daily Chilled Water, Hot Water and Whole Building Electricity
consumption
 G-H: Average Preoccupied Period Outside Air Temperature and Whole building
Electricity consumption
 I-K: Average Occupied Period Outside Air Temperature, Dewpoint-Temperature (or
Relative Humidity) and Whole Building Electricity consumption
 L-M: Average Postoccupied Period Outside Air Temperature and Whole Building
Electricity consumption
 N-O: Daily Simulated Chilled Water and Hot Water Consumption
 The remaining columns are the results of calculations performed upon the data in
columns A-O with user specific inputs on the “Interface” sheet.
Inputs Sheet (building and environment parameters)
This sheet also contains inputs for the model, but this section only contains building and
system parameter based inputs, not inputs that are measurement based. The input sheet
consists of:

In this sheet the physical model system type to use is defined. It is possible to use a
set of up to 5 system types and different sets of parameters simultaneously.
72



















However for most building simulations one system type will be sufficient. By
enabling and disabling individual sets different configurations can be compared
Four system types are currently available to simulate. These include 1. SDRH (Single
Duct Reheat), 2. SZHC (Single Zone Heating and Cooling), 3. DDVAV or DDCV (Dual
Duct Variable Air Volume or Constant Volume) and 4. DFDD (Dual Fan Dual Duct)
Tdewpoint_or_RH – specifies whether the ambient humidity measurement in the
Occupied Period column of the “Data” sheet on the workbook is Dewpoint
temperature (F) – (0) or Relative Humidity (%) – (1)
Total Floor Area and % Interior Zone Area(not subjected to envelope gains/losses)
SWR – Surface Weight Ratio (lb/ft2), typical values depending on construction type
will usually range from (30 – light) to (130 – heavy)
Heating and Cooling Set Point and Night Setback Temperatures
Humidification – Does an electronic humidifier exist? No – (0); Yes –(1). If so, the
electric load required for the latent heat of vaporization of the water is calculated
and subtracted from the whole building electric load to avoid considering this load
as heat gain. This is complemented with the Minimum RH set point
Occupancy Schedules (0-24) hours for Weekdays, Saturdays, Sundays and Vacation
periods
HVAC Schedules (0-24) hours for Weekdays, Saturdays, Sundays and Vacation
periods
Volumetric Flow Rates: Total, Outside Air, Minimum, Leakage, Infiltration. Both for
Exterior Zone and Interior Zone. OA_Control – controls whether the outside air is
controlled at a constant percentage (0) of total flow or a constant flow level (1)
Hot Deck Specifications (DFDD only). HD_onoffTemp, Z_iRH (Interior zone reheat
(1/0)), dT_Rduct (Return air temperature rise)
Economizer: yes/no (1/0), Temperature Set Points, Outside Air Fractions.
Envelope Areas and U-Values: A_Wall, A_Win, U_Wall, U_Win
Supply Fan Efficiency and Total Pressure
Solar Transmission (Btu/hr): A linear interpolation of the given temperatures and
corresponding transmissions is used for simulations throughout the year, the input
values are: T_Jan, q_Jan, T_July, q_July
Area per Occupant for exterior and interior zones (ft2/person)
Lighting and Equipment Heat Gain: Either measured electric loads are used as input
(0) or electric loads are specified (1) from the inputs below. Electric gains for Exterior
and Interior zone for Occupied and Unoccupied periods. Complemented with the
fraction of the measured electric load that contributes to heat gain in the system
simulated (0-1) and the fraction of electric heat gain contributing to respectively the
interior and exterior zone (should sum to 1)
AHU Coil Set Point Temperature Schedules: T_Cset1, T_C1, T_Cset2, T_C2 with linear
interpolation between the given set-points for cooling. Similar for heating set-points
and carried out both for inside air and outside air coils. Coils are disabled in
simulation by entering set-point temperatures to well above or below realistic
values.
Electric Load and HVAC operation Fractions based on day of the week including:
Start and end of the measured electric load for the occupied period (see Data tab)
and factors to adjust the occupied period electric gains and total heating/cooling by
HVAC system (usually always 1)
Vacation period definition
73
C
ABCAT output figures
Figure 45: Set 1 of ABCAT output figures used for basic detection (Peitsman et al., 2010)
a)
CHW measurement and simulation as function of time
b)
HW measurement and simulation as function of time
c)
CHW measurement and simulation as function of ambient temperature
d)
HW measurement and simulation as function of ambient temperature
Figure 46: Set 2 of ABCAT output figures used for additional detection and identification (Peitsman et al., 2010)
a)
Cumulative (measurement-simulation) energy use difference for both CHW and HW simulation
b)
Electricity consumption used for quick check of anomalies in weekly pattern
c)
CHW measurement-simulation difference [%] with 7day moving average
d)
HW measurement-simulation difference [%] with 7day moving average
74
Figure 47: Set 3 of ABCAT output figures used for detection, identification and isolation (Peitsman et al., 2010)
a)
Consecutive days of excess consumption levels
b)
CHW CUSUM alarm, based on cumulative values and RMSE
c)
Bar plot of the diagnostic day count table
d)
HW CUSUM alarm, based on cumulative values and RMSE
Figure 48: Set 4 of ABCAT output figures used detection, identification and isolation (Peitsman et al., 2010)
a)
CHW energy consumption related to ambient temperature, comparison of period 1 and 2
b)
Residuals of the combined CHW and HW energy consumption related to ambient temperature
c)
HW energy consumption related to ambient temperature, comparison of period 1 and 2
d)
Electricity consumption related to the ambient temperature, comparison of period 1 and 2
75
D
Sources for ABCAT inputs and building parameters
Table 6: Time-dependent inputs for ABCAT and their source
Input
Ambient temperature
Ambient relative humidity
Indoor temperature
Indoor relative humidity
Electricity consumption
Source
KNMI
(IMPORTALL.M toevoegen)
KNMI
Priva BMS
Priva BMS
Utility provider
Table 7: Static building parameters for ABCAT and their source
Parameter
Total floor area
Source
EPU
(Utiliteitsgebou
wen, 2009)
Estimate
Value SI
2
6755 m
Value Imperial units
2
72710 ft
Comments
0.9
0.9
Almost every room borders the
envelope
400kg/m
Set-point heating
Set-point cooling
Night setback
EPU
(Utiliteitsgebou
wen, 2009)
BMS
BMS
BMS
21 °C
17 °C
-
69.8 °F
62.6 °F
-
Humidification
BMS
-
-
Occupancy
Weekend occ.
HVAC schedules
Weekend
Volumetric flow
BMS
BMS
BMS
BMS
Carrier
documentation
(Carrier, 2009)
Carrier
documentation
(Carrier, 2009)
Carrier
documentation
(Carrier, 2009)
BMS
EPU
EPU
VABI
VABI
Carrier doc.
Carrier doc.
KNMI
KNMI
7-19h
0
7-21h
7-21h
3
10 m /s
7-19h
0
7-21h
7-21h
21189 CFM
1
1
Only outside air is used
-
-
Constant % control
0
2
2306 m
2
1981 m
6.6
1.1
0.82
-
Not available
VABI
Estimate
0.6
0
2
24813 ft
2
21316 ft
2
0.06 Btu/hrft °F
2
0.01 Btu/hrft °F
0.82
5 / 0 / 3.9 w.g.
30 °F / 90 °F
135713 Btu/h 348815 Btu/h
2
60,48 ft /person
0.6
Priva
-
-
Not 100% available, some are
estimated
Interior zone area
Thermal mass
Outside air ratio
AHU control
Economizer
A_wall
A_win
U_wall
U_win
Fan Efficiency
AHU pressure
Temp Jan & July
Solar transmission
Area per Occupant
heat generation
fraction electric gain
Coil Set Points
2
81.93lb/ft
76
2
No signs of night setback
temperatures
No specific humidification system
present
No weekend and holiday occupancy
HVAC also operational in weekends
Air flow measured at AHU
completion
Combination of irradiation/area and
building total outside area (jan-jul)
E
Characteristic Signatures SWS Son Case-Study Building
T_h + 2degC
10
T_h + 2degC
10
R² = 0.146
HW (%)
CHW (%)
R² = #N/A
0
0
20
40
60
80
100
20
40
60
Outside Temperature (°F)
Outside Temperature (°F)
T_c + 1degC
10
T_c + 1degC
10
R² = 0.6328
HW (%)
CHW (%)
R² = 0.4601
0
0
20
40
60
80
100
-10
20
40
60
80
100
-10
Outside Temperature (°F)
Outside Temperature (°F)
T_hsb + 1degC
10
T_hsb + 1degC
10
R² = 0.5851
HW (%)
R² = 0.7097
0
0
20
40
60
80
100
-10
20
40
60
80
100
-10
Outside Temperature (°F)
Outside Temperature (°F)
T_csb + 1degC
T_csb + 1degC
10
10
R² = #N/A
HW (%)
R² = 0.7165
CHW (%)
100
-10
-10
CHW (%)
80
0
0
20
40
60
80
100
-10
20
40
60
80
100
-10
Outside Temperature (°F)
Outside Temperature (°F)
77
V_eDsqft - 0,01cfmft
10
V_eDsqft - 0,01cfmft
10
R² = 0.6962
HW (%)
CHW (%)
R² = 0.0137
0
0
20
-10
40
60
80
100
Outside Temperature (°F)
40
60
V_iDsqft - 0,01cfmft
10
HW (%)
R² = 0.6962
0
0
20
40
60
80
100
-10
20
40
60
80
100
-10
Outside Temperature (°F)
Outside Temperature (°F)
V_OAeDsqft - 0.01cfmft
10
V_OAeDsqft - 0.01cfmft
10
R² = 0.7097
HW (%)
R² = 0.8039
CHW (%)
100
Outside Temperature (°F)
R² = 0.0086
0
0
20
40
60
80
100
20
40
60
80
100
-10
-10
Outside Temperature (°F)
Outside Temperature (°F)
V_OAiDsqft - 0,01cfmft
10
V_OAiDsqft - 0,01cfmft
10
R² = 0.7097
HW (%)
R² = 0.8039
CHW (%)
80
-10
V_iDsqft - 0,01cfmft
10
CHW (%)
20
0
0
20
40
60
80
100
20
40
60
80
-10
-10
Outside Temperature (°F)
Outside Temperature (°F)
78
100
A_Wall + 10000ft2
10
A_Wall + 10000ft2
10
R² = 0.724
HW (%)
CHW (%)
R² = 0.7106
0
0
20
40
60
80
100
20
40
60
80
-10
-10
Outside Temperature (°F)
Outside Temperature (°F)
A_Window + 10000ft2
10
A_Window + 10000ft2
10
R² = 0.724
HW (%)
CHW (%)
R² = 0.7106
0
0
20
40
60
80
100
-10
20
-10
U_wall decrease of 50%
R² = 0.7106
0
60
80
100
U_wall decrease of 50%
10
HW (%)
CHW (%)
10
40
Outside Temperature (°F)
Outside Temperature (°F)
R² = 0.724
0
20
40
60
80
100
-10
20
40
60
80
100
-10
Outside Temperature (°F)
Outside Temperature (°F)
U_window decrease of 50%
10
U_window decrease of 50%
10
R² = 0.7106
HW (%)
CHW (%)
100
0
R² = 0.724
0
20
40
60
80
100
-10
-10
Outside Temperature (°F)
79
20
40
60
80
Outside Temperature (°F)
100
T_Cset1 + 5 degC
10
T_Cset1 + 5 degC
10
R² = #N/A
HW (%)
CHW (%)
R² = 0.0729
0
0
20
40
60
80
100
-10
40
60
T_C1 + 5 degC
T_C1 + 5 degC
10
HW (%)
CHW (%)
R² = 0.0779
0
0
20
40
-10
60
80
100
Outside Temperature (F)
20
40
-10
60
100
T_Cset2 + 2 degC
10
R² = 0.0729
HW (%)
R² = 0.0195
CHW (%)
80
Outside Temperature (F)
T_Cset2 + 2 degC
10
0
0
20
40
60
80
100
-10
20
40
60
80
100
-10
Outside Temperature (F)
Outside Temperature (F)
T_C2 + 2 degC
10
T_C2 + 2 degC
10
R² = 0.1962
HW (%)
R² = 0.0178
CHW (%)
100
Outside Temperature (F)
R² = 0.0816
0
-10
80
-10
Outside Temperature (F)
10
20
0
20
40
60
80
100
Outside Temperature (F)
-10
80
20
40
60
80
100
Outside Temperature (F)
T_Hset1 + 5degC
10
T_Hset1 + 5degC
10
R² = 0.0729
HW (%)
CHW (%)
R² = 0.0729
0
0
20
40
60
80
100
-10
20
-10
T_H1 + 5 degC
60
HW (%)
CHW (%)
R² = 0.0785
0
0
20
40
60
80
100
-10
20
40
-10
T_Hset2 + 2 degC
10
HW (%)
0
80
100
T_Hset2 + 2 degC
10
R² = 0.0729
60
Outside Temperature (F)
Outside Temperature (F)
CHW (%)
100
T_H1 + 5 degC
10
R² = 0.0785
R² = 0.0729
0
20
-10
40
60
80
100
Outside Temperature (F)
20
40
60
80
100
-10
Outside Temperature (F)
T_H2 + 2 degC
10
T_H2 + 2 degC
10
R² = 0.1964
HW (%)
R² = 0.1964
CHW (%)
80
Outside Temperature (F)
Outside Temperature (F)
10
40
0
0
20
40
60
80
-10
100
20
40
60
80
100
-10
Outside Temperature (F)
Outside Temperature (F)
81
Floor area + 10%
Floor area + 10%
10
R² = 0.8037
HW (%)
CHW (%)
10
0
R² = 0.0736
0
20
40
60
80
100
-10
20
40
60
80
-10
Outside Temperature (F)
Outside Temperature (F)
Themal Mass -30%
10
Themal Mass -30%
10
R² = #N/A
HW (%)
CHW (%)
R² = 0.4562
0
0
20
40
60
80
100
-10
20
40
60
80
100
-10
Outside Temperature (F)
Outside Temperature (F)
Area per Occupant +10%
10
Area per Occupant +10%
10
R² = 0.7441
R² = 0.6785
HW (%)
CHW (%)
100
0
0
20
40
60
80
-10
100
20
40
60
80
-10
Outside Temperature (F)
Outside Temperature (F)
82
100
F
Details of subsystem measurements
Plant/Heat pumps/Gas Use
The building HVAC system’s main heating and cooling plant consists of four gas-powered
heat pumps from ‘GasEngineering/ Aisin Toyota Group ’(GasEngineering, 2011). A running
heat pump which is either in heating or cooling operation mode bus is also able to deliver
free engine heat on the side. The HVAC setup also includes a hot water boiler used for peak
demand heating situations but it’s activity and share in the overall heating energy use is
assumed to be very low and therefore neglected. Gas use measurement data is obtained
from the existing energy monitoring activities using the Maestro energy management
system.
Parameters of the heating and cooling system are found in the ‘building delivery report’
(Utiliteitsgebouwen, 2009) and heat pump specifications (GasEngineering, 2011):








Gas engine driven heat pumps
Source: outside air
Heating temperature range: 35C < Tsupply < 45
Backup energy from gas boiler for peak demand
Generation efficiency: Nopw,verw 1.5
System efficiency: Nsys;verw 0.84
Generation efficiency cooling: Nopw;koel 1.95
System efficiency cooling: Nsys;koel 0.84, 0.85, 0.86
From the measured gas consumption quantities, Dutch natural gas energy content, the
average rated COP of the heat-pump array and documented system efficiency the total
combined HW & CHW energy use can be obtained:
Gas Use (m3) * Energy content (MJ/m3) * Heat Pump COP * System efficiency = Combined
HW & CHW Energy Use
Air Handling Units
One idea was to determine the AHU heating /cooling production with the activity and heat
flows in the heating and cooling coils. As can be seen in the figure some temperatures in
these coils are available. Also the supply pump activity and valve control can be derived. The
one parameter that cannot be found or derived is the mass flow through these coils.
Because this is an essential factor to determine the heat flows, this approach is discarded.
83
Figure 49: Schematic overview of AHU office. On the building side temperature and humidity measurements
are available in the BMS. On the ambient side of the AHU (outside air and exhaust air) additional T and RV
measurements using the WiSensys system are applied. This was similar for the AHU restaurant.
Air mass flow in the AHUs. This is a category of measurements we initially missed. After
looking further into the acquisition of this information the operation rpm of the fans were
found in the building management system. They were not present in the History database
but were from that moment on included.
From rpm to air flow was not very easy to convert. A fan performance curve (Gebhardt,
2011) was obtained but the relations to get to the air flow were too complex and essential
information was missing to successfully derive the occurring air flow from fan rpm.
84
Figure 50: Fan performance curves for the fans present in the building AHUs. No direct relation between fan
rpm and resulting air flow was found (Gebhardt, 2011)
There is no simple, direct relation between fan rpm and the resulting air flow, as can be seen
in figure 42. The air flow produced strongly depends on both the static and dynamic
pressure the air flow encounters on its trajectory. In order to calculate the energy for
heating and cooling in the AHU’s the mass flow through the unit ducts is essential. This mass
flow is not logged or measured but can be calculated using the fan operation and
parameters. Fan operation is logged in form of percentage of the maximum rotational
speed. Using this rotational speed in combination with the resistance pressure the fan has to
cope with and other parameters like efficiency and power it should be possible to derive the
volume and mass flow of air through the system.
The office AHU has two Dahlander belt driven fans as can be found in the Carrier AHU
technical specification (Carrier, 2009) that was obtained from the AHU manufacturer. This
means that the fan has two different rotational speeds it can operate at. Investigation
pointed out that the AHU fans operate at their high rpm level at weekdays 07:00 – 18:00 and
at low rpm for the resulting time. The fans are never shut down.
Although the restaurant AHU’s are fit out with variable speed fans they appear not to be
controlled and used this way. The fan rpm is either fixed on a steady operating rpm of about
75% or shut down. This also happens according a strict time schedule which makes an easy
relation for time – rpm possible without any necessary measurements.
85
Other important information derived from the technical specifications is that the occurring
air flow at these operation speeds is measured during the building and testing phase of the
delivery of the AHU’s. Because these speeds are measured for the exact building and setup
they can be assumed to be valid for continuous building HVAC operation.
Table 8: Parameters AHU (Carrier AHU restaurant SWS Eindhoven (Carrier, 2009))
Fan 1
Total pressure
Power
Engine Speed
Volume flow
Air velocity
Fan rpm
Efficiency
Axis power
RZR 11-0280
972 [pa]
3 [kW]
3000 [rpm] (@ 100%)
2250 [rpm] (@ 75%)
1.56 [m3/s]
12.13 [m/s]
3202 [rpm]
70 [%]
2.15 [kW]
Fan 2
Total pressure
Power
Engine speed
Volume flow
Air velocity
Fan rpm
Efficiency
Axis power
RZR 11-0355
918 [pa]
2.2 [kW]
1500 [rpm] (@ 100%)
1125 [rpm] (@ 75%)
1.44 [m3/s]
7.13 [m/s]
2098 [rpm]
77 [%]
1.72 [kW]
The calculation of the exact air volume flow brings some problems because of the complex
relation (Gebhardt, 2011) between pressure, power, efficiency, fan rotation and volume
flow. Therefore, for now, the following approximation of the air volume flow will be applied:
Table 9: AHU fan speed to air flow conversions for AHU restaurant variable frequency drive fans
Frequency control
100%
75%
0%
Fan 1 speed
3202 rpm
2402 rpm
0 rpm
Fan 2 speed
2098 rpm
1574 rpm
0 rpm
Fan 1 airflow
1.56 m3/s
1.44 m3/s
0 m3/s
Fan 2 airflow
1.17 m3/s
1.08 m3/s
0 m3/s
The fans in this AHU operate from 6.00 to 21.00 for every day of the workweek. During
nighttime and weekends the fans are shut down. For now I assume AHU airflows of
1.44m3/s (fan1) and 1.08m3/s (fan2) for all operation hours.
AHU office
The same assumptions are used for now, a linear relation of the fan rpm and airflow. The air
flow at 750rpm is an assumption, not a given value.
Table 10: AHU fan speed to air flow conversions for AHU office Dahlander control fans
Dahlander control
2
1
0
Fan 1 speed
1500 rpm
750 rpm
0 rpm
Fan 2 speed
1500rpm
750 rpm
0 rpm
86
Fan 1 airflow
9.72 m3/s
4.86 m3/s
0 m3/s
Fan 2 airflow
10.28 m3/s
5.14 m3/s
0 m3/s
Induction Circuit
The pressure difference over the main control valve of the induction circuit pipeline is
measured. Using conversion factors given in the valve documentation the pressure
difference is converted to the flow in the induction circuit in (m3/s).
Figure 51: TA Link pressure sensor & Example of flow measurement application on a control valve (Andersson,
2010)
The flow combined with the supply and return temperatures, which are measured in the
Priva BMS, yields the energy flows present in the induction circuits, as is displayed in the
overview in figure 45. This procedure is carried out for both the HW and CHW circuit.
M
Figure 52: Overview of the entire HW system for explanation of the induction subsystem measurements.
Induction subsystem = blue box, Temperature measurements = T, Flow measurement = M (Priva, 2011)
87
G
Measurement accuracy, reliability and validation
Most measurement data is obtained from common BMS system. The Priva BMS is supplied
with Siemens, industry grade sensors for temperature and relative humidity. The accuracy of
these sensors is not thoroughly tested. Sources in literature indicate that common industry
BMS sensors are accepted as sufficiently accurate for building FDD purposes.
PRIVA sensor accuracy
The sensors used are typical industrial sensors, and their accuracies are respectively ±0.5%
for temperature sensors and ±5% for relative humidity. These values should be taken into
account when determining the threshold for fault detection.
The WiSensys sensors were calibrated for a previous project. The actual measurement
results were checked for accuracy when setting up the sensors for this project’s
measurements.
(Siemens, 2011) gives little information about the accuracy of their sensors. However they
do mention that the actual sensors are standard pt100 and pt1000 components which
means they have the same properties as the sensors used by WiSensys. The accuracy is
given in the WiSensys sensor specifications (WiSensys, 2012):
Measurement range 10% to 95%RH non-condensing
-20°C to +80°C
Measurement accuracy
±3%RH from 20% to 80%RH; ±5%RH otherwise
±0.4°C @ 25°C, ±1°C from 0°C to +50°C,
±2°C from -20°C to +80°C
Measurement resolution 0.1%RH, 0.1°C
Long term stability Drift < 0.5%RH per year
TA-Link Δp measurement
However for the parameters measured through the additional, self installed, measurement
Table 11: conversions and accuracies for the different links in the flow measurement setup
Step in conversion
Δp Measurement
Control valve
Logger
Description
TA Link
TA DN100 valve
WiSensys voltage logger
Conversion
0-100kPa  0-10V
Q = √Δp *100*KV
0-10 V
Accuracy
<± 1 kPa
± 0.1 V
These inaccuracies together can be processed into a flow dependent total inaccuracy, which
is displayed in the following figure:
88
50.0%
150
1
10
19
28
37
46
55
64
73
82
91
100
0.0%
KV factor
200
Error
100.0%
-50.0%
KV DN100
KV DN80
100
50
0
-100.0%
0.5 1.5 2.5 3.5 4.5 5.5 6.5 7.5
dp measuremnt [kPa]
Vale opening setting
Figure 53: Figures used for the validation of TA-Link accuracy
It can be seen that for low Δp the error becomes gigantic. The higher the Δp, the lower the
error gets. In order to achieve accurate water flow measurements, the control valve should
be closed so far that the pressure difference over it becomes in the range of 30-100 kPa.
Beware; closing the valve too far will influence the building water flow and heating/cooling
behavior. Closing the valve ever further will breach the pressure sensor’s maximum range of
100 kPa, resulting in malfunction.
Δp over the control valve is measured and using the manufacturer’s formula and ‘valve
setting value’, KV, the volume flow can be calculated.
The following figure shows KV in relation to the valve opening setting. (8 is fully open, 0 is
closed). As can be seen the KV behavior is fairly linear and clear for valve opening settings of
3 and higher. Lower valve settings result in low values for KV and thus a less clear relation
and higher accuracy. It is not wise to use a low valve opening.
In order to achieve an acceptable Δp the valve opening setting has been decreased to realize
measurements in an accurate and reliable range.
Measurement reliability
Priva server downtime
Sometimes for unknown reason the Priva History server was not running. The History service
was transferred to a more protected environment to make sure this unwanted downtime
was over.
Connection problems
When the distance between a base-station and sensor package is too high the signal
strength becomes low and connection problems can occur. Sometimes a working connection
was lost because of irregular weather conditions (rain, wind or something).
Also when HVAC maintenance personnel moves sensors because of their activities the
connection can get lost. The base-station was moved around several times to find the
optimal position with minimal downtime.
89
Broken sensors
When comparing the measured RH with KNMI RH data it is easy to detect sensor
malfunction. Even if there is a certain error between KNMI and measurement the real faulty
operation of a sensor can easily be detected. This can be seen in the following figure where
the green graph starts showing completely different and unrealistic readings from the end of
august.
Figure 54: Relative humidity measurements showing a broken sensor (green), the measurements are
continued using data from KNMI (blue). The data from both sources shows a close match.
Measurement setup trouble shooting
Some of the sensors and logging processes of these sensors are a constant cause of trouble.
Continuous watching and troubleshooting are required to keep the setup up and running.
List of issues:




History being disabled for some reason, detection and manual enabling required.
Resulting in data loss: holes like can be seen in the following figure
One of the virtual sensors (PRIVA input) had a flaw in the translation from PRIVA to
the WiSensys database. WiSensys showed completely different data than the source
from that data. One error in Matlab could be found fixing the problem partially.
Other causes of this fault are still unknown. Solved by adding an additional virtual
sensor and repeating every step of the translation. Manual upload of data.
Sensor breakdown because of water damage
Disconnection of the base station because it was sent away for software updates.
WiSensys informally reassured us the intermediate measurement data would be
stored in the sensors itself, and would still be uploaded after reconnection of the
base station some days later. This appeared to be the case for most of the sensors
and most of the data, but not for everything. This can be seen in following figures.
90
Figure 55: Example of WiSensys system downtime, indicating flaws in system reliability
Measurement validation
AHU operation measurements
The behavior of the air handling unit fans can be assessed by plotting the fan control
readings from the building management system for a couple of days. The figures are not a
good example because they contain a gap of lost measurement data.
Fans AHU office [1500/750/0 rpm]
2.5
Fan 1
2
Fan 2
1.5
1
0.5
0
6-06-11 0:00 8-06-11 0:00 10-06-11 0:0012-06-11 0:0014-06-11 0:0016-06-11 0:0018-06-11 0:00
Figure 56: The AHU office is equipped with fans with Dahlander control, which means they have two fixed
speeds they can operate at. Observation of the fan behavior shows they are at full speed (1500 rpm) during
occupation and at half speed (750 rpm) while the building is unoccupied
100
Fans AHURestaurant [%]
80
Fan 1
60
Fan 2
40
20
0
6-06-11 0:00 8-06-11 0:00 10-06-11 0:0012-06-11 0:0014-06-11 0:0016-06-11 0:0018-06-11 0:00
Figure 57: The AHU restaurant is equipped with variable frequency fans. The fans though are operated in a
strict schedule of: activated at 75% during occupation and off while the building is unoccupied
91
Measurement replacement by KNMI data
Figure 58: Temperature measurements from different sources (BMS sensor, WiSensys sensor and KNMI) are
compared. They do not show a very strong correlation but it is acceptable for the total building FDD purpose.
During sensor downtime the WiSensys measurements are replaced with KNMI data
92
H
Subsystem results
AHU office & restaurant
For the caclulation of the energy recovery in the office AHU both the temperature and the
relative humidity are required in three different points. The measurement setup supplies
these for the outside air, return air (air subtracted from inside of the builiding) and exhaust
air. From the temperature and relative humidity the enthalpy is calculated. From the three
obtained enthalply’s the total energy recovery by energy wheel Qrecovery is calculated, which
is an important step in the acquisition of the total heating/cooling supplied by the AHU.
Figure 59: During the measurement data processing phase subsystem results, including the air handling units,
were plotted and observed to validate the expected behavior and absence of anomalies
Induction system
Figure 60: During the measurement data processing phase subsystem results, including the induction circuit,
were plotted and observed to validate the expected behavior and absence of anomalies
93
Figure 61: Induction heating and cooling energy flows in comparison with the outside temperature
Temperatures and flow combined results in the actual heat transfer by the induction system
which has frequently is the induction system heating and cooling in comparison with the
outside temperature. Important observations on the initial energy analysis of the building
were done with these figures.
94
I
Details on the HVAC control improvements
The unlocking of heat pumps
In the central controller the four heat pumps are unlocked depending on the outside
temperature. One of the hydro modules (heat pump) is always unlocked for cooling
purposes. This hydro module is used to maintain the CHW buffer tank set point
temperature. The main advantage of this control is that there is always free engine heat
available, which can be used in case there is a (slight) heat demand for the HW circuit. In this
case it is not necessary to enable a heat pump for heating.
Improvement: Summer/winter block. For an outside temperature < 5oC (adjustable) no heat
pumps are unlocked for cooling purposes. For an outside temperature > 25oC (adjustable) no
heat pumps are unlocked for heating purposes.
Heat pump selection
The heat pumps are switched on a daily or weekly basis and in case of malfunction another
heat pump will automatically take over. The heat pump selection can be applied
automatically or manually. Heat pump switching should occur during the night to exclude
heating/cooling performance loss. The number of startups/shutdowns and operation time
per pump are registered and this information is included in the selection process of the heat
pumps. Heat pump startup/shutdown should be kept to a minimum in order to save heat
pump lifetime.
Improvement: A heat pump is not allowed to be started up more than three times per hour.
Multiple heat pumps are enabled/disabled in cascade order.
Heat pump heating operation
The heat pumps are currently not disabled due to too high/low return temperatures.
Improvement: If the return temperature > 40oC (adjustable), one of the working heat pumps
is shut down. After a given latency, the process is repeated to see if more pumps can be shut
down. For supply temperature > 45oC (adjustable), first the circulation pump of the engine
heat is shut down. The superfluous heat is released to the outside air. In case the supply
temperature drops below the set point again, the pump is re-enabled. A certain latency
(adjustable) is applied to this process.
Heat pump cooling operation
During operation the buffer tank set point temperature is maintained. The secondary supply
temperature is set at 9°C. Based on the residual of the calculated and measured secondary
supply temperature one or more heat pumps are enabled for cooling. The return
temperature is monitored, if it drops below 11°C (adjustable), one heat pump is shut down.
Hot water boiler
The hot water boiler is unlocked in case there is a heating demand AND the HW supply
temperature becomes significantly lower than the HW supply set point temperature OR
when the heat pomp configuration gives an error signal. To avoid repeated enabling and
disabling a 5 minute latency is used.
95
Floor heating and radiators
This represents a very small share of the total building heating. They work autonomous of
the BMS. Heat is obtained from the hot water circuit and the share of these heating
subsystems is included in the calculations of the induction circuit.
Induction circuit control
The amounts of water delivered from the plant to the induction circuits is controlled by
valves actuated by a PID controller. The PID controller determines the valve setting from the
HW and CHW set-point curves and the actually measured supply temperature. The HW and
CHW set-point curves are depending on the outside temperature and are configured as
follows:
Temperature set-point
Induction heating
Outside temperature X1 = -10°C (adjustable)
Set-point temperature Y1 = 50°C (adjustable)
Outside temperature X2 = 15°C (adjustable)
Set-point temperature Y2 = 40°C (adjustable)
60
40
HW
20
CHW
0
-20
Induction cooling
Outside temperature X1 = -10°C (adjustable)
Set-point temperature Y1 = 15°C (adjustable)
Outside temperature X2 = 15°C (adjustable)
Set-point temperature Y2 = 1°C (adjustable)
-10
0
10
Outside temperature
20
30
Figure 62: The heating and cooling curves for the
induction system. Temperature set-points are
related to the outside temperature
These are temperature settings for the water that is produced and made available in the
induction circuits. These temperatures do not indicate the heating/cooling actually
delivered. The heating/cooling on room level is controlled locally by thermostat
readjustment which defines the desired temperature and the mix of HW and CHW required
to achieve this supply temperature.
AHU control
In case the outside temperature during the day exceeds 24oC the night ventilation is
unlocked. During the night the ventilation is activated when the room temperature remains
above a certain set-point temperature and, on the other hand, the outside temperature is
sufficiently low as well. When the room temperature drops below a second set-point
temperature the night ventilation is deactivated again. The cooling and heating coil are not
active during night ventilation.
Delayed startup. When the outside temperature is below some threshold the AHU will
operate with a delayed startup. The delay time is configurable. The supply air temp set-point
will start at a significantly higher temperature. After the delayed startup the supply air will
be decreased with 0.1oC per time unit until it reaches the original set-point.
Temperature control
The AHU supply temperature is controlled depending on the calculated and measured
supply air temperature. A supply temperature curve specifies the desired supply
temperature depending on the outside temperature. A heating and cooling coil fed with
hot/cold water from the plant are used to realize the demanded temperature.
96
The AHU supply air temperature is not very
determining for the actual heating or cooling supplied
to the indoor environment. The AHU does not have a
significant capacity for heavy heating or cooling. The
induction system supplies of the majority of heating and
cooling.
97
Temperature set-point
AHU temperature curve
Outside temperature X1 = 0°C (adjustable)
Set-point temperature Y1 = 21°C (adjustable)
Outside temperature X2 = 20°C (adjustable)
Set-point temperature Y2 = 16°C (adjustable)
25
20
15
10
5
0
-10
0
10
20
Outside temperature
Figure 63: AHU temperature curve
30
J
M-files for data processing
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Version 3.0 of the PRIVA History Uploader
%
% This uploader - imports his instructions from settings.mat
%
%
- checks last uploaded data from lastupload.mat %
% Latest improvements 16/08/2011 Fix decimals in Wysensys upload %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%load settings
auth='944b9aa7b823b3caf26ce169d37990c0'; % required for server
authentication
load settings.mat % which includes the definition of which parameters to
upload
enoughdata = 1; % variable which is used when checking if there is new data
to process
%start log, an errolog is written and if necessary it is send by email
delete errorlog.txt
diary errorlog.txt
error = 0;
%check activity, there is a button to temporarily deactivate the program
without having
%to remove it
if settings.on == 1
disp('uploads are scheduled, program running')
disp(' ')
else
disp('nothing is scheduled, program closing')
disp(' ')
close
end
%check upload tasks
if settings.numberofuploads > 1
disp(sprintf('%d wisensys uploads are planned',settings.numberofuploads))
disp(' ')
elseif settings.numberofuploads ==1
disp(sprintf('%d wisensys upload is planned',settings.numberofuploads))
disp(' ')
else %I started on a email upload as well but it is never put into use
disp(sprintf('no wisensys uploads planned, moving on to emails'))
end
%% open and format starttime
% try to find lastupload.mat
try
% open lastupload.mat
load lastupload.mat % tells the program until which timestep the data is
already transfered
lastuploadd = 1;
disp('last upload found, only uploading new data')
catch
disp('no previous upload found, uploading all data')
disp(' ') % if there is no 'lastupload.mat' the program will upload all
the data it can find
lastuploadd = 0;
end
if lastuploadd ==1
% the MSAccess query system uses time notations which are much different
% from Matlab time syntax. Conversion is required.
[a,b,c,d,e,f]=datevec(lastupload);
b = formatt(b);
98
c = formatt(c);
d = formatt(d);
e = formatt(e);
f = 0;
f = formatt(f);
%format the start time for query syntax
starttime = sprintf('%s%s%s%s%s%d
%s%s%s%s%s%s','#',b,'/',c,'/',a,d,':',e,':',f,'#');
else
end
%% Set db connection preferences with setdbprefs.
% standard script for database connection
s.DataReturnFormat = 'cellarray';
s.ErrorHandling = 'store';
s.NullNumberRead = 'NaN';
s.NullNumberWrite = 'NaN';
s.NullStringRead = 'null';
s.NullStringWrite = 'null';
s.JDBCDataSourceFile = '';
s.UseRegistryForSources = 'yes';
s.TempDirForRegistryOutput = '';
setdbprefs(s)
% Make connection to database. Note that the password has been omitted.
% connect... database name, login, password
conn = database('History','','');
%% start loop of imports and uploads
for i = 1:settings.numberofuploads
% the parameter name in MSAccess database and ID for worksphere
% database are extracted from the settings file
if settings.numberofuploads == 1
upload = settings.upload{i};
ID = settings.ID{i};
else
upload = cell2mat(settings.upload{i});
ID = cell2mat(settings.ID{i});
end
sdtid=ID; % one by one the parameters are addressed with onscreen
notifications
disp(sprintf('uploading %s to ID: %s',upload,ID)) % let op. cell2mat
gebruikt!
try
%% extract specified data from the access db
% one version for defined time range, one version for upload without time
% boundary
if lastuploadd == 1
Time = fetch(conn, sprintf('SELECT ALL Systeemtijd FROM "%s" WHERE
Systeemtijd > %s',upload,starttime));
Value = fetch(conn, sprintf('SELECT ALL Waarde FROM "%s" WHERE Systeemtijd >
%s',upload,starttime));
else
Time = fetch(conn, sprintf('SELECT ALL Systeemtijd FROM "%s" WHERE
Systeemtijd',upload));
Value = fetch(conn, sprintf('SELECT ALL Waarde FROM "%s" WHERE
Systeemtijd',upload));
end
catch %detection of failure: error message + assignment to send error
email
error = 1;
disp('something failed in database communications, sending error log');
end
99
% If the newly extracted data is very little (less than 10 entries) it is
% not worth it to continue, about all the data is on the worksphere
% server already, the user is advised to try again later
if length(Time) < 10
disp('not enough data to upload, try again later')
enoughdata = 0;
else
end
% in the settings file it is stated if a parameter needs an additional
% devision in order to get to the correct value (a lot of temperatures are
% a factor 10 too high and must be corrected)
try
divided = settings.divide{i,1};
divided = cell2mat(divided);
catch
divided = settings.divide{i};
end
divided = str2num(divided);
if enoughdata ==1
% application of the division correction
if divided == 1
valuee = cell2mat(Value);
valuee = valuee * 0.1;
Value = valuee;
disp('values divided by ten')
else
disp('no division required')
Value = cell2mat(Value);
end
%% The actual upload
data=''; %empty vector which will be filled with data in the loop below
% the upload script for the worksphere database required again a different
% syntax for the time vector + data points. it will be converted here.
for j = 1:length(Time)
Time2 = Time{j,1};
aa = str2num(Time2(1:4));
bb = str2num(Time2(6:7));
cc = str2num(Time2(9:10));
dd = str2num(Time2(12:13));
ee = str2num(Time2(15:16));
ff = str2num(Time2(18:19));
Timedatenum(j)=datenum(aa,bb,cc,dd,ee,ff);
% the actual syntax for data upload to worksphere database
data = strcat(data, sprintf('%04d %02d %02d,%02d %02d %02d,%3.1f;',
aa,bb,cc,dd,ee,ff , Value(j)));
end
% the upload to the server.. using urlread with the targed ID,
% authentication key and data string as formatted above
try
params={'sdtid',sdtid,'auth',auth,'data',data}; %parameters string
[S,status] =
urlread('http://www.gebouwinbeeld.nl/import.matlab.php','post',params); %url
write command
catch
error = 1; % if this script fails there is an error report for server
connection problems
disp('something failed in server communications, sending error log')
end
else
end
100
end
% uploads are finished
disp('scheduled upload finished. see you later')
%% Close database connection.
close(conn)
clear conn s
if enoughdata ==1
%store last uploaded time value, this value will be used the next time the
%program is run to define the time range
lastupload=datenum(Time(length(Time)));
save lastupload.mat
else
end
%close log
diary off
%message
if error ==0;
report = 'The PRIVA export was successfull';
else
report = 'The PRIVA export has failed';
end
% email script
% Define these variables appropriately:
mail = '[email protected]'; %Your GMail email address
password = 'privaexport1'; %Your GMail password
% Then this code will set up the preferences properly:
setpref('Internet','E_mail',mail);
setpref('Internet','SMTP_Server','smtp.gmail.com');
setpref('Internet','SMTP_Username',mail);
setpref('Internet','SMTP_Password',password);
props = java.lang.System.getProperties;
props.setProperty('mail.smtp.auth','true');
props.setProperty('mail.smtp.socketFactory.class',
'javax.net.ssl.SSLSocketFactory');
props.setProperty('mail.smtp.socketFactory.port','465');
% Send the email. Note that the first input is the address you are sending
the email to
file = 'errorlog.txt';
sendmail('[email protected]',report,report,file)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Version 2.1 of the Import Tool
%
% This importer retrieves all the new data from the server/database
% and puts them in a local .mat file for the calculations in the
% following m-files
%
% Latest improvements 6/11/2011
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
clear all
close all
clc
%
%
%
%
%
%
Choose which data should be imported
1 = wysensys sensors (T, RV etc.)
2 = KNMI
3 = AHU office
4 = AHU office FANS
5 = AHU restaurant
101
%
%
%
%
%
w
q
6 = AHU restaurant FANS
7 = Room conditions
8 = dp induction circuit
9 = temperatures induction circuits
10 = Energy date from excel
= 7;
= 2; %for excel only. 1 = new, else = addition
% choose time range
% Take extra care in choosing these values
% overlap in time range results in overwriting of values
begint = datenum(2012, 3, 1, 00, 00, 00);
endt = datenum(2012, 5, 1, 00, 00, 00);
disp('importer started')
starttime = datevec(begint) %display begin and endtime for validation
endtime = datevec(endt)
% authentication key for database access
auth='944b9aa7b823b3caf26ce169d37990c0';
% load excisting data
load alldata
% format timerange values
[s_year, s_month, s_day, s_hour, s_min, s_sec] = datevec(begint);
[e_year, e_month, e_day, e_hour, e_min, e_sec] = datevec(endt);
a=formatt(s_year);
b=formatt(s_month);
c=formatt(s_day);
d=formatt(s_hour);
e=formatt(s_min);
f=formatt(s_sec);
g=formatt(e_year);
h=formatt(e_month);
i=formatt(e_day);
j=formatt(e_hour);
k=formatt(e_min);
l=formatt(e_sec);
%% DATA IMPORTS
% Step 1: Wysensys sensors
if w == 1
%% temp sensor 041
SDTID=637;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
102
% Add up previous data with new data
% after that filter and sort unique data
alldata.timet041 = [alldata.timet041; data(:,1)];
alldata.t041 = [alldata.t041; data(:,2)];
[alldata.timet041,I,J]=unique(alldata.timet041);
alldata.t041 = alldata.t041(I);
% show the last uploaded timepoint for validation purposes
lastuploaded = datevec(alldata.timet041(length(alldata.timet041)))
%% temp sensor 042
SDTID=638;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
% splitsen tijd en data
olddata = length(alldata.t042)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timet042 = [alldata.timet042; data(:,1)];
alldata.t042 = [alldata.t042; data(:,2)];
[alldata.timet042,I,J]=unique(alldata.timet042);
alldata.t042 = alldata.t042(I);
%% temp sensor 043
SDTID=640;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
% splitsen tijd en data
olddata = length(alldata.t043)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timet043 = [alldata.timet043; data(:,1)];
alldata.t043 = [alldata.t043; data(:,2)];
[alldata.timet043,I,J]=unique(alldata.timet043);
103
alldata.t043 = alldata.t043(I);
%% temp sensor 053
SDTID=642;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
% splitsen tijd en data
olddata = length(alldata.t043)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timet053 = [alldata.timet053; data(:,1)];
alldata.t053 = [alldata.t053; data(:,2)];
[alldata.timet053,I,J]=unique(alldata.timet053);
alldata.t053 = alldata.t053(I);
%% RH sensor 043
SDTID=639;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
% splitsen tijd en data
olddata = length(alldata.t043)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.time043 = [alldata.time043; data(:,1)];
alldata.RH043 = [alldata.RH043; data(:,2)];
[alldata.time043,I,J]=unique(alldata.time043);
alldata.RH043 = alldata.RH043(I);
%% RH sensor 053
SDTID=641;
m1=num2str(SDTID);
% download data from website
104
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
% splitsen tijd en data
olddata = length(alldata.t043)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.time053 = [alldata.time053; data(:,1)];
alldata.RH053 = [alldata.RH053; data(:,2)];
[alldata.time053,I,J]=unique(alldata.time053);
alldata.RH053 = alldata.RH053(I);
% confirmation of last stored timestamp
laststoreddate = datevec(alldata.time053(length(alldata.time053)))
% % % % % % % %% pyranometer
% % % % % % % SDTID=62;
% % % % % % % m1=num2str(SDTID);
% % % % % % %
% % % % % % % clear data
% % % % % % %
% % % % % % % % download data from website
% % % % % % % params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':'
e ':' f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
% % % % % % % data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% % % % % % %
% % % % % % % % standaard tijd omzetten naar datenum tijd
% % % % % % % length(data)
% % % % % % %
% % % % % % % data=datahandle(data);
% % % % % % %
% % % % % % % olddata = length(alldata.t043)
% % % % % % % newdata = length(data)
% % % % % % %
% % % % % % % % Add up previous data with new data
% % % % % % % % after that filter and sort unique data
% % % % % % % alldata.timepyro = [alldata.timepyro; data(:,1)];
% % % % % % % alldata.pyro = [alldata.pyro; data(:,2)];
% % % % % % %
% % % % % % % [alldata.timepyro,I,J]=unique(alldata.timepyro);
% % % % % % % alldata.pyro = alldata.pyro(I);
% Step 2: KNMI data
elseif w == 2
knmidata =
urlwrite('http://www.knmi.nl/klimatologie/uurgegevens/datafiles/370/u
urgeg_370_2011-2020.zip','knmidata.zip');
unzip('knmidata.zip');
newData1 = importdata('uurgeg_370_2011-2020.txt');
105
% Create new variables in the base workspace from those fields.
vars = fieldnames(newData1);
for i = 1:length(vars)
assignin('base', vars{i}, newData1.(vars{i}));
end
date = num2str(data(:,2));
hour = data(:,3);
%produce the real date in datenum
for i = 1:length(date)
a = str2num(date(i,1:4));
b = str2num(date(i,5:6));
c = str2num(date(i,7:8));
date2(i) = datenum(a,b,c,hour(i),0,0);
end
Time = date2;
Temperatuur = data(:,8)./10;
RH = data(:,18);
alldata.timeKNMI = Time';
alldata.TKNMI = Temperatuur;
alldata.RHKNMI = RH;
laststoreddate = datevec(alldata.timeKNMI(length(alldata.timeKNMI)))
% Step 3: AHU OFFICE
elseif w == 3
%% T1
SDTID=637;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
size(data);
% conversion of website time to datenum
data=datahandle(data);
% splitsen tijd en data
olddata = length(alldata.t043)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.time1 = [alldata.time1; data(:,1)];
alldata.T1 = [alldata.T1; data(:,2)];
[alldata.time1,I,J]=unique(alldata.time1);
alldata.T1 = alldata.T1(I);
%% RH1
SDTID=641;
106
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
% splitsen tijd en data
olddata = length(alldata.t043)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timeRH1 = [alldata.timeRH1; data(:,1)];
alldata.RH1 = [alldata.RH1; data(:,2)];
[alldata.timeRH1,I,J]=unique(alldata.timeRH1);
alldata.RH1 = alldata.RH1(I);
% datevec(data(length(data),1))
%% T2
SDTID=640;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.t043)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.time2 = [alldata.time2; data(:,1)];
alldata.T2 = [alldata.T2; data(:,2)];
[alldata.time2,I,J]=unique(alldata.time2);
alldata.T2 = alldata.T2(I);
%% RH2
SDTID=639;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
107
% conversion of website time to datenum
data=datahandle(data);
% Add up previous data with new data
% after that filter and sort unique data
alldata.timeRH2 = [alldata.timeRH2; data(:,1)];
alldata.RH2 = [alldata.RH2; data(:,2)];
[alldata.timeRH2,I,J]=unique(alldata.timeRH2);
alldata.RH2 = alldata.RH2(I);
%% T3
SDTID=643;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.T3)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.time3 = [alldata.time3; data(:,1)];
alldata.T3 = [alldata.T3; data(:,2)];
[alldata.time3,I,J]=unique(alldata.time3);
alldata.T3 = alldata.T3(I);
%% T4
SDTID=645;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.T4)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.time4 = [alldata.time4; data(:,1)];
alldata.T4 = [alldata.T4; data(:,2)];
[alldata.time4,I,J]=unique(alldata.time4);
alldata.T4 = alldata.T4(I);
108
% laststoreddate = datevec(alldata.time4(length(alldata.time4)))
% Step 4: AHU office fans
elseif w == 4
%% fan1
SDTID=646;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
alldata.timefan1 = data(:,1);
alldata.fan1=data(:,2);
%% fan2
SDTID=647;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
alldata.timefan2 = data(:,1);
alldata.fan2=data(:,2);
%% AHU RESTAURANT
elseif w == 5
%% rest T1
SDTID=637;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
109
olddata = length(alldata.T1rest)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.time1rest = [alldata.time1rest; data(:,1)];
alldata.T1rest = [alldata.T1rest; data(:,2)];
[alldata.time1rest,I,J]=unique(alldata.time1rest);
alldata.T1rest = alldata.T1rest(I);
%% rest T2
SDTID=648;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.T1rest)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.time2rest = [alldata.time2rest; data(:,1)];
alldata.T2rest = [alldata.T2rest; data(:,2)];
[alldata.time2rest,I,J]=unique(alldata.time2rest);
alldata.T2rest = alldata.T2rest(I);
%% rest T3
SDTID=649;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.T1rest)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.time3rest = [alldata.time3rest; data(:,1)];
alldata.T3rest = [alldata.T3rest; data(:,2)];
110
[alldata.time3rest,I,J]=unique(alldata.time3rest);
alldata.T3rest = alldata.T3rest(I);
%% rest T4
SDTID=650;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.T1rest)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.time4rest = [alldata.time4rest; data(:,1)];
alldata.T4rest = [alldata.T4rest; data(:,2)];
[alldata.time4rest,I,J]=unique(alldata.time4rest);
alldata.T4rest = alldata.T4rest(I);
laststoreddate =
datevec(alldata.time4rest(length(alldata.time4rest)))
%% fan1 rest
elseif w == 6
SDTID=652;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
alldata.timefan1rest = data(:,1);
alldata.fan1rest=data(:,2);
%% fan2
SDTID=653;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
111
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
alldata.timefan2rest = data(:,1);
alldata.fan2rest=data(:,2);
%% RUIMTE CONDITIES
elseif w == 7
%% floor1
SDTID=658;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.Tfloor1)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timefloor1 = [alldata.timefloor1; data(:,1)];
alldata.Tfloor1 = [alldata.Tfloor1; data(:,2)];
[alldata.timefloor1,I,J]=unique(alldata.timefloor1);
alldata.Tfloor1 = alldata.Tfloor1(I);
% floor2
SDTID=659;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.Tfloor2)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timefloor2 = [alldata.timefloor2; data(:,1)];
112
alldata.Tfloor2 = [alldata.Tfloor2; data(:,2)];
[alldata.timefloor2,I,J]=unique(alldata.timefloor2);
alldata.Tfloor2 = alldata.Tfloor2(I);
%% floor3
SDTID=660;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.Tfloor3)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timefloor3 = [alldata.timefloor3; data(:,1)];
alldata.Tfloor3 = [alldata.Tfloor3; data(:,2)];
[alldata.timefloor3,I,J]=unique(alldata.timefloor3);
alldata.Tfloor3 = alldata.Tfloor3(I);
%% floor4
SDTID=661;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.Tfloor4)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timefloor4 = [alldata.timefloor4; data(:,1)];
alldata.Tfloor4 = [alldata.Tfloor4; data(:,2)];
[alldata.timefloor4,I,J]=unique(alldata.timefloor4);
alldata.Tfloor4 = alldata.Tfloor4(I);
laststoreddate =
datevec(alldata.timefloor4(length(alldata.timefloor4)))
%% RH3
SDTID=644;
m1=num2str(SDTID);
% download data from website
113
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.RH3)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timeRH3 = [alldata.timeRH3; data(:,1)];
alldata.RH3 = [alldata.RH3; data(:,2)];
[alldata.timeRH3,I,J]=unique(alldata.timeRH3);
alldata.RH3 = alldata.RH3(I);
%% INDUCTIE CIRCUITS
elseif w ==8
%% dp hot
SDTID=664;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.dphot)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timedphot = [alldata.timedphot; data(:,1)];
alldata.dphot = [alldata.dphot; data(:,2)];
[alldata.timedphot,I,J]=unique(alldata.timedphot);
alldata.dphot = alldata.dphot(I);
clear data
% dp cold
SDTID=665;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
114
% conversion of website time to datenum
data=datahandle(data);
olddata = length(alldata.dpcold)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timedpcold = [alldata.timedpcold; data(:,1)];
alldata.dpcold = [alldata.dpcold; data(:,2)];
[alldata.timedpcold,I,J]=unique(alldata.timedpcold);
alldata.dpcold = alldata.dpcold(I);
laststoreddate =
datevec(alldata.timedpcold(length(alldata.timedpcold)))
%% heating Tin
elseif w == 9
SDTID=654;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
% Add up previous data with new data
% after that filter and sort unique data
alldata.timeTHWin = [alldata.timeTHWin; data(:,1)];
alldata.THWin = [alldata.THWin; data(:,2)];
[alldata.timeTHWin,I,J]=unique(alldata.timeTHWin);
alldata.THWin = alldata.THWin(I);
%% heating Tout
SDTID=655;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
% Add up previous data with new data
% after that filter and sort unique data
alldata.timeTHWout = [alldata.timeTHWout; data(:,1)];
alldata.THWout = [alldata.THWout; data(:,2)];
[alldata.timeTHWout,I,J]=unique(alldata.timeTHWout);
115
alldata.THWout = alldata.THWout(I);
%% cooling Tin
SDTID=656;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
% Add up previous data with new data
% after that filter and sort unique data
alldata.timeTCHWin = [alldata.timeTCHWin; data(:,1)];
alldata.TCHWin = [alldata.TCHWin; data(:,2)];
[alldata.timeTCHWin,I,J]=unique(alldata.timeTCHWin);
alldata.TCHWin = alldata.TCHWin(I);
%% cooling Tout
SDTID=688;
m1=num2str(SDTID);
% download data from website
params1 = {'sdtid',m1,'start',[a '-' b '-' c ' ' d ':' e ':'
f],'end',[g '-' h '-' i ' ' j ':' k ':' l],'auth',auth};
data
=
str2num(urlread('http://www.gebouwinbeeld.nl/export.matlab.php','GET'
,params1));
% conversion of website time to datenum
data=datahandle(data);
% splitsen tijd en data
olddata = length(alldata.TCHWout)
newdata = length(data)
% Add up previous data with new data
% after that filter and sort unique data
alldata.timeTCHWout = [alldata.timeTCHWout; data(:,1)];
alldata.TCHWout = [alldata.TCHWout; data(:,2)];
[alldata.timeTCHWout,I,J]=unique(alldata.timeTCHWout);
alldata.TCHWout = alldata.TCHWout(I);
elseif w ==10
%
q = 1; % 1 for fresh excel import, 2 for addition of some new
data, with unique function
if q == 1
%% Elektricity Use
116
newData1 = importdata('Electricityson.xls');
% version with UNIX timestamp
time = newData1.data;
[a b c d e f]=datevec(time);
a = a+1900;
c = c-1;
time=datenum(a,b,c,d,e,f);
value = newData1.textdata(2:length(newData1.textdata),4);
% operation to remove the 'KWh' string from the input values
for i = 1:length(value)
value2 = value{i};
b = str2num(value2(1:length(value2)-3));
valuenum(i)=b;
end
value = valuenum';
% removal of double entries
value = value(find(unique(time)));
time = unique(time);
alldata.timeElec = time;
alldata.Elec = value;
clear time value newData1
%% Gas Use
newData1 = importdata('Gasson.xls');
time = newData1.data;
[a b c d e f]=datevec(time);
a = a+1900;
c = c-1;
time=datenum(a,b,c,d,e,f);
value = newData1.textdata(2:length(newData1.textdata),4);
for i = 1:length(value)
value2 = value{i};
b = str2num(value2(1:length(value2)-4));
valuenum(i)=b;
end
value = valuenum';
% removal of double entries
value = value(find(unique(time)));
time = unique(time);
alldata.timeGas = time;
alldata.Gas = value;
% laatstewaardesExcel =
datevec(alldata.timeGas(length(alldata.timeGas)))
else % here is the addition part
%% Elektricity Use
newData1 = importdata('Electricityson.xls');
% versie met timestamp (data als nummer)
time = newData1.data;
117
[a b c d e f]=datevec(time);
a = a+1900;
c = c-1;
time=datenum(a,b,c,d,e,f);
value = newData1.textdata(2:length(newData1.textdata),4);
for i = 1:length(value)
value2 = value{i};
b = str2num(value2(1:length(value2)-3));
valuenum(i)=b;
end
value = valuenum';
timeold = alldata.timeElec;
elecold = alldata.Elec;
timenew = [timeold;time];
elecnew = [elecold;value];
value = elecnew(find(unique(timenew)));
time = unique(timenew);
alldata.timeElec = time;
alldata.Elec = value;
clear time value newData1
%% Gas Use
newData1 = importdata('Gasson.xls');
clear time
time = newData1.data;
[a b c d e f]=datevec(time);
a = a+1900;
c = c-1;
time=datenum(a,b,c,d,e,f);
value = newData1.textdata(2:length(newData1.textdata),4);
for i = 1:length(value)
value2 = value{i};
b = str2num(value2(1:length(value2)-4));
valuenum(i)=b;
end
value = valuenum';
clear timeold
timeold = alldata.timeGas;
gasold = alldata.Gas;
timenew = [timeold;time];
gasnew = [gasold;value];
value = gasnew(find(unique(timenew)));
time = unique(timenew);
alldata.timeGas = time;
alldata.Gas = value;
118
laatstewaardesExcel =
datevec(alldata.timeGas(length(alldata.timeGas)))
end
end
disp('finished')
save alldata alldata
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Calculations for Heating and Cooling Energy AHU office
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% regular initiation
clear all
close all
clc
% loading and definition of the used parameters
load alldata % .mat file with all measurement data
load CP % table with CP values
time1 = alldata.time1;
time2 = alldata.time2;
time3 = alldata.time3;
time4 = alldata.time4;
Tout = alldata.T1;
Tsup = alldata.T4;
Tret = alldata.T3;
Texh = alldata.T2;
T1 = Tout;
T2 = Texh;
T3 = Tret;
T4 = Tsup;
timeRH1 = alldata.timeRH1;
timeRH2 = alldata.timeRH2;
timeRH3 = alldata.timeRH3;
RH1 = alldata.RH1;
RH2 = alldata.RH2;
RH3 = alldata.RH3;
%outside
%exhaust
%return
% the vectors are cut to the same lenght.. starting at the maximum value of
% the first entry of eacht vector and ending at the minimum value of the
% last entry of each vector
startt =
max([time1(1),time2(1),time3(1),time4(1),timeRH1(1),timeRH2(1),timeRH3(1)]);
endd =
min([time1(length(time1)),time2(length(time2)),time3(length(time3)),time4(le
ngth(time4)),timeRH1(length(timeRH1)),timeRH2(length(timeRH2)),timeRH3(lengt
h(timeRH3))]);
% display of the start and endtime of the synchronized vectors
starttime = datevec(startt)
endtime = datevec(endd)
% a time vector is created to represent the vector of the correct length
% and making use of a step size of 8 minutes
Time = startt:datenum(0,0,0,0,8,0):endd;
Time = Time';
%all vectors are interpolated to fit this vector... and giving all
%parameter vectors the same step size
T1 = interp1(time1,T1,Timefixed);
T2 = interp1(time2,T2,Timefixed);
T3 = interp1(time3,T3,Timefixed);
119
T4 = interp1(time4,T4,Timefixed);
RH1 = interp1(timeRH1,RH1,Timefixed);
RH2 = interp1(timeRH2,RH2,Timefixed);
RH3 = interp1(timeRH3,RH3,Timefixed);
% old values are cleared
clear Timefixed starttime endtime time1 time2 time3 time4 timeRH1 timeRH2
timeRH3
% calculation of the enthalpy at the three measured points in the air
% handling unit outside, exhaust and return position
for i = 1:length(Time)
H1(i) = interp1(CP.Tdry,CP.CPdry,T1(i)+273)*(T1(i)+273) +
RH1(i)*interp1(CP.Tvap,CP.CPvap,T1(i)+273)*(T1(i)+273);
H2(i) = interp1(CP.Tdry,CP.CPdry,T2(i)+273)*(T2(i)+273) +
RH2(i)*interp1(CP.Tvap,CP.CPvap,T2(i)+273)*(T2(i)+273);
H3(i) = interp1(CP.Tdry,CP.CPdry,T3(i)+273)*(T3(i)+273) +
RH3(i)*interp1(CP.Tvap,CP.CPvap,T3(i)+273)*(T3(i)+273);
end
H1=H1';
H2=H2';
H3=H3';
% figure of intermediate results
figure
plot(Time,H1,Time,H2,Time,H3)
legend('H outside','H exhaust','H return')
title('Enthalpys AHU office')
xlabel('Time')
ylabel('Enthalpy [kj/kgK]')
datetick
%
%
%
%
%
% save the image
filetype = '-dtiff';
resolution = '-r750';
title2 = 'Enthalpy AHUoffice2';
print(filetype,resolution,title2)
% dahlander 1500/750 rpm
% the air flow is determined from the operation schedules (measurement was
% not possible)
timevector = datevec(Time);
for i = 1:length(Time)
if weekday(Time(i)) >1 & weekday(Time(i)) < 7 % selection of the day of
the week (workday and weekend operation)
if timevector(i,4) >= 9 & timevector(i,4) <21 % selection of the
time of the day (AHU operation hours 9-21)
v1(i) = 9.72;
v2(i) = 10.28;
else
v1(i) = 4.86;
v2(i) = 5.14;
end
else
v1(i) = 4.86;
v2(i) = 5.14;
end
end
% all values in m3/s
% convesion to Kelvins for further processing
T1 = T1+273;
T2 = T2+273;
T3 = T3+273;
T4 = T4+273;
% table with air density values in degC
Trho =[-40
120
-20
0
20
40
60
80
100]';
Trho = Trho+273;
rho = [1.52 %kg/m3
1.40
1.293
1.205
1.127
1.067
1.000
0.946]';
% just to test wether there are still NaN's present
NaNcount = 0;
% Energy calculations
for i = 1:length(Time)
%
q[m3/s] rho[kg/m3]
Cp[kj/kgK] T[K] --> Q[kW]
Qout(i) = v1(i) * interp1(Trho,rho,T1(i)) * interp1(CP.Tdry,CP.CPdry,T1(i))
* T1(i); %energy flow entering the AHU from outside air
test1(i) = interp1(Trho,rho,T1(i)); %partial calculation to validate if data
and calculations are correct
if isnan(test1(i))
NaNcount = count+1; % count Not a Numbers
end
test2(i) = interp1(CP.Tdry,CP.CPdry,T1(i)); %partial calculation to validate
if data and calculations are correct
Qsup(i) = v1(i) * interp1(Trho,rho,T4(i)) * interp1(CP.Tdry,CP.CPdry,T4(i))
* T4(i); %energy flow supplied to the building
Qrec(i) = v2(i) * interp1(Trho,rho,(T4(i)+T2(i))/2) *
interp1(CP.Tdry,CP.CPdry,(T4(i)+T2(i))/2) * (T2(i)-T4(i)); %energy flow from
heat recovery
end
Qin = Qsup-Qout-Qrec; %the energy supplied to the AHU via the heating and
cooling coil.. which is the thermal energy consumption
Qout = Qout';
NaNcount %for calculation and data validation
Timeplot = Time; % time vector for plots
Qinplot = interp1(Time,Qin,Timeplot);
% the energy flow inserted to the AHU must be devided in heating and
% cooling
for i = 1:length(Qinplot)
if Qinplot(i)>= 0
heat(i)=Qinplot(i);
cool(i)=NaN;
else
cool(i)=Qinplot(i);
heat(i)=NaN;
end
end
% figure of AHU heating and cooling results
figure
plot(Timeplot,heat,'r',Timeplot,cool,'b','linewidth',2)
legend('Qin heating','Qin cooling')
xlabel('Time')
ylabel('Heat flow [kW]')
datetick
121
title('Illustration heating/cooling power AHU office')
% the same but with 0 instead of NaN's which is required for ABCAT
for i = 1:length(Qinplot)
if Qinplot(i)>= 0
heat(i)=Qinplot(i);
cool(i)=0;
else
cool(i)=Qinplot(i);
heat(i)=0;
end
end
% calculations results are stored in the alldata.mat
alldata.timeoffice = Timeplot;
alldata.qinoffice= Qinplot;
alldata.qheatoffice = heat';
alldata.qcooloffice = -cool';
save alldata alldata
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Calculations for Heating and Cooling Energy AHU Restaurant
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% regular initiation
close all
clear all
clc
% loading and definition of the used parameters
load alldata % .mat file with all measurement data
load CP % table with CP values
T1
T2
T3
T4
=
=
=
=
alldata.T1rest;
alldata.T2rest;
alldata.T3rest;
alldata.T4rest;
length(alldata.T1rest)
length(alldata.T2rest)
length(alldata.T3rest)
% the vectors are cut to the same lenght.. starting at the maximum value of
% the first entry of eacht vector and ending at the minimum value of the
% last entry of each vector
startt =
max([alldata.time1rest(1),alldata.time2rest(1),alldata.time3rest(1)])
endd =
min([max(alldata.time1rest),max(alldata.time2rest),max(alldata.time3rest)])
% a time vector is created to represent the vector of the correct length
% and making use of a step size of 8 minutes
Timefixed = startt:datenum(0,0,0,0,8,0):endd;
Timefixed = Timefixed';
Time2=Timefixed;
%all vectors are interpolated to fit this vector... and giving all
%parameter vectors the same step size
T1 = interp1(alldata.time1rest,T1,Timefixed);
T2 = interp1(alldata.time2rest,T2,Timefixed);
T3 = interp1(alldata.time3rest,T3,Timefixed);
T4 = interp1(alldata.time4rest,T4,Timefixed);
% old values are cleared
122
clear Time end1 end2 starttime endtime
% table with air density values in degC
Trho =[-40
-20
0
20
40
60
80
100]';
Trho = Trho+273;
rho = [1.52 %kg/m3
1.40
1.293
1.205
1.127
1.067
1.000
0.946]';
% change the temperatures to kelvin
T1 = T1+273;
T2 = T2+273;
T3 = T3+273;
T4 = T4+273;
%% get air mass flow
% the air flows are determined from the operation schedules
%(measurement was not possible)
timevector = datevec(Time2);
for i = 1:length(Time2)
if weekday(Time2(i)) >1 & weekday(Time2(i)) < 7
if timevector(i,4) >= 9 & timevector(i,4) <21 %only active on
working days between 9 and 21h
v1(i) = 1.44;
v2(i) = 1.08;
else
v1(i) = 0;
v2(i) = 0;
end
else
v1(i) = 0;
v2(i) = 0;
end
end
% all values in m3/sec
% we have m[m3/s], rho[kg/m3], Cp[kj/kgK], and T[K] --> Q in [kW]
for i = 1:length(T1)
Qout(i) = v1(i) * interp1(Trho,rho,T1(i)) * interp1(CP.Tdry,CP.CPdry,T1(i))
* T1(i);
Qsup(i) = v1(i) * interp1(Trho,rho,T4(i)) * interp1(CP.Tdry,CP.CPdry,T4(i))
* T4(i);
Qrec(i) = v2(i) * interp1(Trho,rho,(T4(i)+T2(i))/2) *
interp1(CP.Tdry,CP.CPdry,(T4(i)+T2(i))/2) * (T2(i)-T4(i));
end
Qin = Qsup-Qout-Qrec; %the energy supplied to the AHU via the heating and
cooling coil.. which is the thermal energy consumption
Timeplot = Time2; %time vector for plots
Qinplot = Qin;
123
% the energy flow inserted to the AHU must be devided in heating and
% cooling
for i = 1:length(Qinplot)
if Qinplot(i)>= 0
heat(i)=Qinplot(i);
cool(i)=NaN;
else
cool(i)=Qinplot(i);
heat(i)=NaN;
end
end
% figure of AHU heating and cooling results
figure
plot(Timeplot,heat,'r',Timeplot,cool,'b','linewidth',2)
legend('Qin heating','Qin cooling')
xlabel('Time')
ylabel('Heat flow [kW]')
datetick
title('Illustration heating/cooling power AHU restaurant')
% the same but with 0 instead of NaN's which is required for ABCAT
for i = 1:length(Qinplot)
if Qinplot(i)>= 0
heat(i)=Qinplot(i);
cool(i)=0;
else
cool(i)=Qinplot(i);
heat(i)=0;
end
end
% calculations results are stored in the alldata.mat
alldata.timerest = Timeplot;
alldata.qinrest = Qinplot;
alldata.qheatrest = heat';
alldata.qcoolrest = -cool';
save alldata alldata
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Calculations for Heating and Cooling Energy AHU office
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% regular initiation
close all
clear all
clc
% loading and definition of the used parameters
load alldata % .mat file with all measurement data
load CP % table with CP values
dphot = alldata.dphot;
dpcold = alldata.dpcold;
THWin = alldata.THWin;
THWout = alldata.THWout;
TCHWin = alldata.TCHWin;
TCHWout = alldata.TCHWout;
timedphot = alldata.timedphot;
timedpcold = alldata.timedpcold;
timeTHWin = alldata.timeTHWin;
timeTHWout = alldata.timeTHWout;
timeTCHWin = alldata.timeTCHWin;
124
timeTCHWout = alldata.timeTCHWout;
% the vectors are cut to the same lenght.. starting at the maximum value of
% the first entry of eacht vector and ending at the minimum value of the
% last entry of each vector
startt =
max([timedphot(1),timedpcold(1),timeTHWin(1),timeTHWout(1),timeTCHWin(1),tim
eTCHWout(1)])
endd =
min([timedphot(length(timedphot)),timedpcold(length(timedpcold)),timeTHWin(l
ength(timeTHWin)),timeTHWout(length(timeTHWout)),timeTCHWin(length(timeTCHWi
n)),timeTCHWout(length(timeTCHWout))]);
% a time vector is created to represent the vector of the correct length
% and making use of a step size of 8 minutes
starttime = datevec(startt)
endtime = datevec(endd)
% maak de juiste tijdvector aan
Timefixed = startt:datenum(0,0,0,1,0,0):endd;
Time = Timefixed;
%all vectors are interpolated to fit this vector... and giving all
%parameter vectors the same step size
dphot = interp1(timedphot,dphot,Timefixed);
dpcold = interp1(timedpcold,dpcold,Timefixed);
THWin = interp1(timeTHWin,THWin,Timefixed);
THWout = interp1(timeTHWout,THWout,Timefixed);
TCHWin = interp1(timeTCHWin,TCHWin,Timefixed);
TCHWout = interp1(timeTCHWout,TCHWout,Timefixed);
% old values are cleared
clear Timefixed starttime endtime time1 time2 time3 time4 timeRH1 timeRH2
timeRH3
% table with water density values in degC
% T [C]
TRHO = [100
80
60
40
30
25
22
20
15
10
4
0
-10
-20];
TRHO = TRHO+273; %in K
% RHO water [kg/m3]
RHO= [958.4
971.8
983.2
992.2
995.6502
997.0479
997.7735
998.2071
999.1026
999.7026
999.972
999.8395
1000
1000];
125
%% calculations
% flow(formulas from TAlink manufacturer)
% the control valve opening settings are changed twice in the meaurement
% period. For both the changes a factor in the equations had to be altered,
% resulting in three individual calculations
for t = 1:length(Time)
if Time(t) <= datenum(2011,9,28,16,0,0)
flowhot(t) = 100.*80.*dphot(t).^0.5./1000;
elseif Time(t) <= datenum(2011,10,3,13,40,0)
flowhot(t) = 100.*44.*dphot(t).^0.5./1000;
else
flowhot(t) = 100.*16.*dphot(t).^0.5./1000;
end
flowcold(t) = 100.*41.*dpcold(t).^0.5./1000;
end
% in m3/h
time=Time;
%% PLOTS
% Plot, temperatures in Hot water circuit and chilled water circuit
% for a clearer view temperatures are converted to degC
figure(1)
subplot(2,1,1)
plot(time,THWin(1:length(time)),time,THWout(1:length(time)))
legend('THWin','THWout','location','SouthWest')
title('Hot water Circuit');
xlabel('time');
ylabel('temperature [^oC]');
datetick
axis tight
subplot(2,1,2)
plot(time,TCHWin(1:length(time)),time,TCHWout(1:length(time)))
legend('TCHWin','TCHWout','location','NorthWest')
title('Chilled water Circuit');
xlabel('time');
ylabel('temperature [^oC]');
datetick
axis tight
% flow in m3/h
figure(2)
plot(time,flowhot(1:length(time)),'r-',time,flowcold(1:length(time)),'b-')
legend('Hot water flow','Cold water flow','location','NorthWest')
title('water volume flows');
xlabel('time');
ylabel('flow [m3/h]');
datetick
axis tight
% Temperatures to Kelvin
THWin = THWin+273;
THWout = THWout+273;
TCHWin = TCHWin+273;
TCHWout = TCHWout+273;
%heat transfer calculation
for i = 1:length(time)
% here values in m3/h are inserted
% calculation
flow kg/s = flow m3/s
flowhot(i) = flowhot(i) / 60 / 60 *
interp1(TRHO,RHO,(THWin(i)+THWout(i))/2);
flowcold(i) = flowcold(i) /60 / 60 *
interp1(TRHO,RHO,(TCHWin(i)+TCHWout(i))/2);
126
/60 /60
* rho
% now they are kg/s
% heat flow calculation
% Q[kW] =
m[kg/s]
*
Cp[kj/kg K]
* dT[K]
--> kW
Qhot(i) = flowhot(i) *
interp1(CP.TCPwater,CP.CPwater,(THWin(i)+THWout(i))/2) * (THWin(i) THWout(i));
Qcold(i) = flowcold(i) *
interp1(CP.TCPwater,CP.CPwater,(TCHWin(i)+TCHWout(i))/2) * (TCHWout(i) TCHWin(i));
end
% temperature vector from KNMI temperature data
TKNMI = interp1(alldata.timeKNMI,alldata.TKNMI,time);
% Plot flow in kg/s and heat transfer in KW
figure(3)
subplot(2,1,1)
plot(time,flowhot(1:length(time)),'r-',time,flowcold(1:length(time)),'b-')
legend('Hot water flow','Cold water flow','location','NorthWest')
title('Water mass flows');
xlabel('time');
ylabel('mass flow [kg/s]');
datetick
axis tight
subplot(2,1,2)
plot(time,Qhot(1,1:length(time)),'r-',time,-Qcold(1,1:length(time)),'b','LineWidth',1)
legend('Hot water energy','Cold water energy','location','NorthWest')
title('Energy flows');
xlabel('time');
ylabel('Heat Energy flow [kW]');
datetick
axis tight
% Plot flow in kg/s and heat transfer in KW
figure(4)
subplot(2,1,1)
plot(time,TKNMI,'b-')
title('Outside Temperature');
xlabel('time');
ylabel('Temp [^oC]');
datetick
axis tight
subplot(2,1,2)
plot(time,Qhot(1,1:length(time)),'r-',time,-Qcold(1,1:length(time)),'b','LineWidth',1)
legend('Hot water energy','Cold water energy','location','NorthWest')
title('Energy flows');
xlabel('time');
ylabel('Heat Energy flow [kW]');
datetick
axis tight
% calculations results are stored in the alldata.mat
alldata.tQhot = time;
alldata.tQcold = time;
alldata.Qhot = Qhot;
alldata.Qcold = Qcold;
save alldata alldata
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
Combination of subsystem results into whole building results
%
%
+ preperation of ABCAT inputs
%
127
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% regular initiation
close all
clc
clear all
% definition of the target time period
starttime = datenum(2011,8,1,0,0,0);
endtime = datenum(2012,4,8,0,0,0);
% import and definition of variables
load alldata
% heating
theatind = alldata.tQhot;
theatrest = alldata.timerest;
theatoffice = alldata.timeoffice;
heatind = alldata.Qhot;
heatrest = alldata.qheatrest;
heatoffice = alldata.qheatoffice;
%cooling
tcoolind= alldata.tQcold;
tcoolrest = alldata.timerest;
tcooloffice = alldata.timeoffice;
coolind = alldata.Qcold;
coolrest = alldata.qcoolrest;
cooloffice = alldata.qcooloffice;
% interpolation to 10min values
time = starttime:datenum(0,0,0,0,10,0):endtime;
timevec = datevec(time);
heatind = interp1(theatind,heatind,time);
heatrest = interp1(theatrest,heatrest,time);
heatoffice = interp1(theatoffice,heatoffice,time);
coolind = interp1(tcoolind,coolind,time);
coolrest = interp1(tcoolrest,coolrest,time);
cooloffice = interp1(tcooloffice,cooloffice,time);
% clearign old variables
clear theatind theatoffice theatrest tcoolind tcooloffice tcoolrest
% the basic summation of subsystems
heattotal = heatind + heatrest + heatoffice;
cooltotal = coolind + coolrest + cooloffice;
% from kW to kWh = interpolation to hourly values
timeh = starttime:datenum(0,0,0,1,0,0):endtime;
heatkWh = interp1(time,heattotal,timeh);
coolkWh = interp1(time,cooltotal,timeh);
heatofficekWh = interp1(time,heatoffice,timeh);
coolofficekWh = interp1(time,heatoffice,timeh);
Tdin = interp1(alldata.timeTdin,alldata.Tdin,timeh)';
Troom = interp1(alldata.timeTroom,alldata.Troom,timeh)';
Elechour = interp1(alldata.timeElec,alldata.Elec,timeh)';
Gashour = interp1(alldata.timeGas,alldata.Gas,timeh)';
% removal of NaN's
for i = 1:length(Tdin)-1
if isnan(Tdin(i)) ==1
Tdin(i)=(Tdin(i-1)+Tdin(i+1))/2; %NaN is replaced by the average of
the previous and next entry
end
end
128
% creation of daily values
timeday2 = starttime:datenum(0,0,1,0,0,0):endtime;
Tdout = interp1(alldata.timeTdout,alldata.Tdout,timeday2)';
Tout = interp1(alldata.time1,alldata.T1,timeday2)';
% voor Tdin alleen waardes voor 7-18 uur
% preocc = 0-7
daystart = 7; % occ = 7-18
dayend = 18; % postocc = 18-24
% calculation of daily values and preoccupied - occupied - postoccupied
% values
i = 1;
try
while i~=0
heatkWhday(i) = sum(heatkWh((i-1)*24+(1:24)));
coolkWhday(i) = sum(coolkWh((i-1)*24+(1:24)));
heatofficekWh2(i) = sum(heatofficekWh((i-1)*24+(1:24)));
coolofficekWh2(i) = sum(coolofficekWh((i-1)*24+(1:24)));
Elecday(i) = sum(Elechour((i-1)*24+(1:24)));
timeday(i) = datenum(2011,8,1,0,0,0)+i;
Gasday(i) = sum(Gashour((i-1)*24+(1:24)));
Troompreocc(i) = sum(Troom((i-1)*24+(1:daystart)))/(daystart-1);
Elecpreocc(i) = sum(Elechour((i-1)*24+(1:daystart)))/(daystart-1);
Troomocc(i) = sum(Troom((i-1)*24+(daystart:dayend)))/(dayenddaystart);
Tdinocc(i) = sum(Tdin((i-1)*24+(daystart:dayend)))/(dayenddaystart);
Elecocc(i) = sum(Elechour((i-1)*24+(daystart:dayend)))/(dayenddaystart);
Troompostocc(i) = sum(Troom((i-1)*24+(dayend:24)))/(24-dayend);
Elecpostocc(i) = sum(Elechour((i-1)*24+(dayend:24)))/(24-dayend);
i = i+1;
end
catch
disp('time vector processed, all daily values calculated')
end
% again some NaN's must be removed
for i = 1:length(Tdinocc)-1
if isnan(Tdinocc(i)) ==1
Tdinocc(i)=(Tdinocc(i-1)+Tdinocc(i+1))/2;
end
end
% processing into matrix for correct 'bar plot' representation
Troom2 = [Troompreocc',Troomocc',Troompostocc'];
Tdew = [Tdout(1:length(Tdout)-1),Tdinocc'];
Elec = [Elecpreocc',Elecocc',Elecpostocc'];
% make sure there is no negative cooling
for i = 1:length(coolkWhday)
if coolkWhday(i) < 0
coolkWhday(i)=0;
end
end
timedayfixed = timeday2-1;
EleckWh = interp1(alldata.timeElec,alldata.Elec,timeday);
Gas = interp1(alldata.timeGas,alldata.Gas,timedayfixed);
% figure#1 energy consumptions in relation with the outside temperature
129
figure
subplot(3,1,1)
bar(timedayfixed(1:length(timedayfixed)-1),heatkWhday,'r')
title('Heating Energy Use per day')
xlabel('Time')
ylabel('Heating Energy [kWh]')
datetick
axis tight
subplot(3,1,2)
bar(timedayfixed(1:length(timedayfixed)-1),coolkWhday)
title('Cooling Energy Use per day')
xlabel('Time')
ylabel('Cooling Energy [kWh]')
datetick
axis tight
subplot(3,1,3)
bar(timedayfixed,Tout,'g')
title('Average outside temperature')
xlabel('Time')
ylabel('Temperature [^oC]')
datetick
axis tight
% figure#2 energy consumptions in relation with the gas consumption
figure
subplot(4,1,1)
bar(timedayfixed(1:length(timedayfixed)-1),heatkWhday,'r')
title('Heating Energy Use per day')
xlabel('Time')
ylabel('Heating Energy [kWh]')
datetick
axis tight
subplot(4,1,2)
bar(timedayfixed(1:length(timedayfixed)-1),coolkWhday)
title('Cooling Energy Use per day')
xlabel('Time')
ylabel('Cooling Energy [kWh]')
datetick
axis tight
subplot(4,1,3)
bar(timedayfixed(1:length(timedayfixed)-1),Gasday,'g')
title('Gas Use per day')
xlabel('Time')
ylabel('Gas Consumption [m3/day]')
datetick
axis tight
subplot(4,1,4)
bar(timedayfixed(1:length(timedayfixed)-1),heatkWhday+coolkWhday,'y')
title('Combined Energy Use per day')
xlabel('Time')
ylabel('Energy Use [kWh]')
datetick
axis tight
% figures for gas consumption -> energy use correlation
figure
scatter(Gasday,heatkWhday+coolkWhday,2)
figure
scatter(heatkWhday+coolkWhday,Gasday)
%% formattation to ABCAT columns
Tout;
Tdout;
timeday2 = timeday2';
CHW = coolkWhday';
HW = heatkWhday';
Elecday = Elecday';
130
Troompreocc = Troompreocc';
ELECpre = Elec(:,1);
Troomocc = Troomocc';
Tdewocc = Tdinocc';
ELECocc = Elecocc';
Tpost = Troompostocc';
ELECpost = Elecpostocc';
% one matrix containing all processed data ready for ABCAT implementation
toABCAT = [timeday2(1:length(Tout)-1),Tout(1:length(Tout)1),Tdout(1:length(Tout)1),CHW,HW,Elecday,Troompreocc,ELECpre,Troomocc,Tdewocc,ELECocc,Tpost,ELECpos
t];
131