Data Logger Essentials for Building Commissioning
by Bryan W. Welsh, P.E.
January 7, 2008
Data loggers are powerful analysis tools that can be used to
evaluate complex building relationships and solve control problems.
Data loggers and the subsequent analysis of thousands of points
of data can also be a huge waste of time if improperly applied. There are
standard procedures and techniques that can help assure that the data logging
tools are used for maximum effectiveness.
This article focuses on stand-alone data loggers in conjunction
with the logging capabilities of the BAS in the context of use by a
commissioning provider. It also provides tips and advice on specific procedures
and techniques that will enable the efficient and effective use of data loggers
to analyze building performance.
DATA LOGGING APPLICATIONS
|
|
| Measurements. (Click on the chart for an enlarged view.) |
|
Two of the most common reasons for using data logging in building
commissioning is to demonstrate performance or for system troubleshooting. The
following are some common performance demonstration and troubleshooting
scenarios.
Performance
• Log occupied space environmental parameters (temperature, rh,
CO2, lighting, noise) to demonstrate that the facility meets the contract
requirements for the purposes of acceptance. This is generally straightforward;
the system either meets the requirements or it does not.
• Log occupied space environmental parameters to demonstrate to
an occupant that their environment meets standards. This can be more
complicated, as even faced with hard data, some people will feel that the space
is not adequate.
• Log overall building or specific system energy use to prove
energy savings in support of a utility funded project, therefore receiving grants
or funding. In this case it is critical to have a highly accurate approach as
considerable money can be involved.
• Energy use logging to support a Monitoring & Verification
Plan to qualify for a USGBC LEED point.
Troubleshooting
• Logging occupied spaces and system parameters to evaluate why a
space is having (confirmed) environmental control problems.
• Log space temperature at various distances from the ceiling to
evaluate stratification and short-circuiting problems.
• Log duct static pressure, hydronic loop differential pressure
or HVAC unit discharge temperature to evaluate and adjust system loop tuning
and response.
• Log building static pressure and various HVAC equipment
parameters to evaluate why the building static pressure fluctuates all the time
to the point of slamming doors or blowing them open.
• Log economizer damper positions and various HVAC temperatures
and parameters to evaluate causes for high energy use, occupant comfort
problems, or other problems.
• Log economizers to verify warm-up period and optimum start/stop
functions.
• Log system and component start/stop times to verify scheduling.
• Log lighting controls for conformance to schedule, light
levels, and occupancy.
• Log heating and chilled water plant parameters to evaluate
causes of high energy use and poor performance.
DATA LOGGER OPERATION
There are a wide variety of data logging devices available and
the exact operation of each cannot be covered here. There are certain steps
that will be required regardless of the particular unit and they are as
follows:
• Planning
• Configuration
• Deployment
• Recovery
• Analysis and Reporting
Planning:
As with any endeavor, careful planning will be the difference
between a successful logging project and one that requires excessive data
manipulation at the end or in some cases that has to be done over.
If data logging is being undertaken then there is some goal to be
achieved. A Data Logging Plan (DLP) should be developed outlining the goals and
approach. As with most projects, it is important to start with the end in mind.
The DLP should outline the specific goals to be achieved or a problem statement
outlining the circumstances requiring troubleshooting and hence data logging
and reporting. The following is an outline for the DLP.
• Goals and/or Problem Statement including reporting requirements
(charts, graphs, etc.)
• List of the BAS trend logging capabilities
• List of environmental parameters that are to be measured
including what BAS trend logging points are to be used and what stand-alone
data loggers are to be used
• Accuracy/calibration requirements for all logged points
• Sample interval for all logged points
• Sensor location for all logged points including any special
fixtures required
• Logging period (start/stop date/time) — Identify if there will
be some event during that period that is critical to capture
• Communication Plan: intent, impact, and duration of study with
building owner, facility staff, or occupants
Configuration:
The Data Logging Plan will outline the various parameters for the
logging project. All stand-alone data loggers and all BAS trend log systems
must be configured prior to deployment or starting of trending. The
configuration phase typically will include the following steps.
• Define Points
• Sensor Calibration
• Set Sample Interval
• Set Sample Size
• Set Sample Overrun Option
• Set Start Method
• Synchronize Clocks
• Assign File Name
• Trial Run
Define Points: The BAS and the
stand-alone data logger may or may not have the needed points defined. In both
cases, the individual points need to be activated or turned on. The input type,
sensor range, and other parameters must be set specific to each sensor type.
This is a critical operation and care should be taken to use the correct point
definition for the associated sensor. Many of the sensor definitions appear
very similar and selecting the wrong one will result in significant data
errors. During this step, it is important to use consistent naming conventions
so that the data makes sense later. Often, the names used in the point
definitions are the column headings in the data fields and eventually will be
used in graphical representations. Careful planning at this stage will reduce
the amount of manipulation later when graphs are developed for the report.
Sensor Calibration: If the project is a
critical application the sensors should be calibrated. The calibration should
include the sensor and recording device as configured.
Changes in wire lengths and other variations may invalidate the
calibration. Even if calibration is not required, the calibration should be
checked to ensure relative accuracy. Calibration or calibration checks are done
by subjecting the sensor to a known standard environment such as an ice bath or
calibrated immersion bath.
|
|
| Table 1. Data misalignment due to staggered sample intervals.
(Click on the table for an enlarged view.) |
|
Set Sample Interval: The appropriate
sampling interval is dependent upon the specific application. It used to be
that this was a key trade-off because sample storage was more limited. It was
critical to set the interval just long enough to capture events in the physical
data so as to minimize the number of samples and conserve memory. This
philosophy also drove users to use different intervals for different parameters
in the same logging session. For example, the outside air temperature changes
very slowly so a 15 minute interval might be appropriate for logging it. But 15
minutes is too long to evaluate the dynamics of a mixed air control via
economizer dampers, which may take an interval of 2 minutes or less to evaluate
properly. This practice results in a data table of values that don’t line up
and contains voids, making analysis and graphing very difficult. Table 1
demonstrates what a data table would look like if three measured parameters
were set at logging intervals of 15, 5, and 2 minutes and the logger started at
12:00; the “X” represents data.
Some stand-alone loggers and most BAS trend loggers have a
feature that uses change-of-state or limits to determine when a data point is
logged rather than at a set interval. The change-of-state feature is used on
binary points such as motor start/stop. The limits feature logs analog points
only when a certain limit is reached. Both are designed to reduce the amount of
samples taken, conserve memory, and to capture specific events. Both will
result in data being recorded at arbitrary times that does not line up with the
data logged on intervals. The change-of-state feature has also been known to
cause some BAS logging systems to malfunction and cause data corruption
throughout the entire logging system. These features should only be used in
special cases when an exact event needs to be logged.
Because systems now have such large sampling capacities, it is
practical to set all logging intervals to the same value equal to the least
common denominator. This way, all data lines up and requires minimal
manipulation and smoother data. One downside to this approach is large data
files, which can be unwieldy if they are later manipulated in third party
software such as MS Excel. But the efficiencies gained typically outweigh this
problem, and after all, memory is cheap. The following table contains some
suggested intervals for various typical commissioning logging activities.
Remember, the logging intervals for both the BAS and the stand-alone loggers
should be set the same if the data from these two systems are to
be combined later in the analysis.
|
|
| Table 2. Suggested intervals for various parameters. (Click on
the table for an enlarged view.) |
|
Table 2 contains suggested intervals for various parameters based
on a balance of memory usage and need for detail. These are only suggestions
and the intervals used should always be determined by the specific needs of the
logging project. It is usually better to err on shorter durations so that
short-term events can be captured.
If different sampling intervals are to be used, they should be
common multiples so the data has voids, but lines up. For example: 2 minutes
and 10 minutes, 5 minutes and 30 minutes to achieve short and long intervals.
Set Sample Size: In most BAS trend
logging systems sample size is an option. This is important because system
memory is used for operation of the control system as well as trend logging so
memory conservation is an issue. In stand-alone data loggers, the maximum size
is typically automatically calculated based on the internal memory size, the
number of activated channels, and the logging interval. Setting the sample size
will determine how long the data logging period will be. For example if the
logging interval is 1 hour for a single channel, then a sample size of 48 will
get two full days of logging.
Set Sample Overrun Options: When the
data logger memory is full, there are two options: overwrite the oldest data or
stop logging. The first choice is generally used when a particular event that
is to be logged is not predictable. The most recent data is always in memory so
the user can stop the process after some event significant to the logging plan
has occurred. The second choice of stopping the logging when the memory is full
is useful when the exact logging period is known beforehand.
Set Starting Method: There are
typically several options for starting the beginning of the logging period:
instantly after configuration, at a pre-determined time, event logging, and via
a manual input (push button). Set the appropriate method for the application.
The best option to maintain uniform data integration is starting at a
pre-defined time. In this way, the data from all stand-alone loggers will be in
synch with each other and the BAS trend logger if properly set up. In some
loggers a stop time may also be an option to set.
Synchronize Clocks: There are three
areas of clock synchronization: the stand-alone logger clock(s), the BAS trend
logger clock, and the user’s timepiece. The user’s timepiece should agree with
the other system clocks so the time will agree with the deployment records.
Most stand-alone data loggers will use the system clock of the computer that
launches them so this clock should be set prior to downloading the setup to the
logger. BAS systems can have more than one clock to consider. The BAS graphical
user interface computer has a clock and so does the main BAS controller. Some
BAS systems use the PC while others use the controller clock. Be sure to be
clear on what clock is being used to record the trend data.
Assign File Name: Depending on the
system, a file name may be entered to describe the logging activity. Like
defining the sensor channel names, using a compact yet descriptive file name
can simplify organization activities later.
Download Configuration: Once all
configuration parameters are set, the configuration is downloaded to the data
logger. Typically a BAS trend logger does not require this step, though there
may be some that require a similar step.
Trial Run: It is always advisable to
perform a trial run to ensure that the data is being recorded as intended and
can be recovered in a usable format.
Deployment:
Once the data loggers are configured, the stand-alone data
loggers need to be deployed into the environment to be evaluated. The following
outlines the deployment process.
• Position Loggers and Sensors
• Record Logger Deployment Information
• Verify BAS Trending
• Activate Logger
Position Loggers and Sensors: Position the standalone data loggers and sensors per
the Data Logging Plan. Consideration should be given to who might be in the
area that may interfere with the devices. It is advisable to notify the
occupants if logging activities are to occur in occupied spaces. It is also a
good idea to leave a business card with the devices. Protect loggers from any
environmental conditions it was not designed for. Sensor wires and logging
devices should be secured using screws, clamps, magnets, tie strips, tape, etc.
Care should be taken to ensure that the sensor wires do not become disconnected
from the sensors or data logger; make a final check before leaving
installation.
|
|
| Table 3. Data logger deployment information sheet. (Click on the
table for an enlarged view.) |
|
Record Logger Deployment Information: It
is important to record the location and channel definitions of the stand-alone
loggers along with other pertinent information about the logging project. Use a
standard form such as Table 3.
Verify BAS Trending: Check the BAS
system and verify that the trends are active. Observing the trends in real time
will typically not affect the BAS trend files.
Activate Logger: If the logger was
activated at download or the pre-determined start time option is set, then this
step is not required. For push-button types activate the logger manually. In
all cases, verify that the data record indicator indicates that the unit is
recording. Record the start time and any other pertinent information on the
Data Logger Deployment Information Sheet.
Recovery:
At the end of the data logging period, the stand-alone loggers
are retrieved and the data is recovered from the BAS trend logs and the
stand-alone loggers. The following are the steps for the recovery process:
• Data Logger Upload
• Data Logger Retrieval
• BAS Trend Upload
• Backup Data
Data Logger Upload: Prior to removing
the sensors, the data should be uploaded from the logger in the unfortunate event
that there was a logger malfunction and the logging session needs to be
repeated.
Data Logger Retrieval: Once the data
integrity is verified, the loggers and sensors can be picked up and stored.
BAS Trend Upload: If BAS trend logging
is part of the Data Logging Plan, the trend logs are recovered from the BAS
system. Some BAS systems have the capability to be used for data analysis and
reporting, but in most cases the data will be recovered and combined with the
stand-alone logger data during the Analysis Phase. Most BAS systems are capable
of exporting data files that can be imported by the stand-alone logger software
or a third party tool such as MS Excel. Occasionally some creative tricks must
be used to extract the data out of some BAS trend systems.
For example, some BAS logger systems do not have an export
function, but the text data can be selected in the text-based report in the
trend logging system, then copied and pasted using MS Windows to a text editor.
In this case, the column headings are typically not in the data that is copied
and pasted. Therefore, the user must record what the columns of data represent
for use during the data import phase. Column headings can also be typed
directly into the text editor on-site, being sure to use the exact same
delimiters (discussed later in Data Analysis).
Backup Data: The logging effort to this
point represents a significant investment. Prior to erasing the data off the
loggers or before leaving the site, it is recommended that the data be backed
up. There are inexpensive portable storage devices that plug into USB ports
that work well for the backup and for transferring the data files from the BAS
trend logging system.
Analysis and Reporting:
Once all the pertinent data has been recovered and stored, the
final step is to analyze the data then produce reports that support the goals
of the DLP. There are three basic options for working with the data:
• BAS trending system
• The stand-alone data logging OEM (original equipment
manufacturer) software
• A third party software such as MS Excel
BAS trend log system: As has been
previously mentioned, some BAS trend log systems have decent graphing and
reporting capabilities and others do not. If all that is required is a simple
plot of similar logged parameters to demonstrate compliance with standards,
then BAS trend log systems with graphing capability can usually get the job
done.
If more advanced analysis or reporting is required, then these
systems usually fall short. Typically none have the ability to merge data from
other applications or logging systems. So if stand-alone data loggers are part
of the DLP, then it is likely the data cannot be merged with the BAS data.
A critical issue is that when parameters have large value
differences but need to be compared to each other on a graph, the BAS trend log
system usually cannot be configured to display correctly. For example, displaying
building static pressure (a value around 0.03) along with the relief fan VFD
signal (a value as high as 100) results in a plot of the VFD signal and a
straight line at zero representing the building static pressure. No analysis
can be performed on such a plot. The BAS reporting and graphing outputs
typically cannot be annotated to point out important events in the data.
The BAS graphs cannot be easily transferred to an electronic
report as the function of displaying the graphs resides in the BAS software and
cannot be duplicated away from the BAS operator station. One way to get around
this is to take screen captures of the graphs, then paste them into an
electronic media such as MS Paint where they can be annotated and saved as an
image file. This gets the job done but is cumbersome and the graphs cannot be
revised to emphasize different issues later.
OEM Software: Some OEM software is
fairly limited while others contain extensive features for data analysis. This
paper cannot delve into all the capabilities available (or disadvantages) of
using the software from various providers, but in general if the software can
perform most of the functions outlined under MS Excel below then it would be
the application of choice.
MS Excel: MS Excel is a spreadsheet
application with extensive reporting and graphing capabilities. With the
spreadsheet functions, there is no limit to the operations that can be
performed on the logged data including merging data, scaling data to engineering
units, and cleaning up bad data. The main disadvantage of using MS Excel is
that it takes a few extra steps to bring data into the system then manipulate
it. So if the project does not require the power and flexibility that MS Excel
can provide, then it is most likely better to use the BAS trend logger system
or the OEM software.
APPLICATION EXAMPLE: OFFICE OVERHEATING
|
|
| Figure D. BAS and stand-alone data comparison – zone temperature
control. (Click on the figure for an enlarged view.) |
|
A two-story office building had recently undergone a complete
HVAC retrofit. The system was a four-pipe fan coil with economizers. Two office
spaces were reported as overheating in the afternoon on mild days (60-65° F)
while the remainder of the offices in the area controlled fine. The obvious
things were checked for first, like leaking heating valves, extra load in the
rooms, etc., but these revealed nothing. Stand-alone loggers were set up in the
spaces because there was some level of distrust by the occupants that the BAS
computer was reporting correctly.
Preliminary analysis included setting up stand-alone loggers to
monitor the supply air temperature, space temperature at the thermostat, and
space temperature near where the occupant sits to evaluate zone control and
microclimates. This preliminary analysis did not reveal the problem, but
demonstrated that the system was capable of good control and the BAS trend log
data could be trusted for further analysis. Figure D is a graph from MS Excel
using data collected from both the BAS trend logging system and the stand-alone
data loggers. In this case it demonstrated good room temperature control. It
also shows how sensor calibrations can be different for the different systems.
In this type of analysis, the goal is to find the root cause of the problem and
minor disagreements of a couple of degrees are not significant to the analysis.
As can be seen, both the BAS and stand-alone data show very stable space
control and the absolute value of the space temperature is less of a concern
because it is reflective of the user adjustable space set point.
In Figure D, the problem was being caused by two overlapping
issues that combined to make the situation worse. The economizer dampers
leaked, allowing warmer air to recirculate back resulting in a less effective
economizer function. As a side note, the installation did not include damper access
doors. If they had, then this would have been checked early in the process.
|
|
| Figure E. BAS trend data – occupied space overheating. (Click on
the figure for an enlarged view.) |
|
The more complex issue had to do with the fact that the chiller
was manually shut off by the maintenance staff during this season but the
sequence of operations still activated the system on cooling demand. So as the
room would start to overheat due to the ineffective free cooling in economizer,
the chilled water valve would open, creating a demand for chilled water.
Because the chiller was not enabled, the chilled water loop heated up due to
pumping energy and the pipes passing through ambient spaces. The chilled water
coil then became a heating coil, adding heat to the system and really driving
the space temperature up. Figure E is a graph of the BAS trend data
using MS Excel. The BAS trend logging system did not have the
capability to create this level of graphics.
So in conclusion, the occupant had a legitimate complaint and the
stand-alone data was not really needed to prove anything to them. The dampers
were re-indexed and the sequence of operations was modified to prevent the
chilled water system from running unless there is a status proof after several
minutes of being commanded on.
Reprinted with permission from the Onset Computer Corp.
white paper “Data Logger Essentials for Building Commissioning.”
Publication date: 01/07/2008
|
