Tridium, Inc.
3951 Westerre Parkway
Suite 350
Richmond, Virginia 23233
USA
Energy Management Objects
APPLICATION ENGINEERING NOTES
This note covers the following topics relating to the collection of custom program objects used to perform
energy logging and energy management strategies:
Sliding Window Demand Calculation
• Electric Demand Limiting
• Output Load Shed
• Setpoint Load Shed
• Setpoint Offset (Reset) Control
• Optimized Start Stop
• Outside Air Optimization
• Night Purge Control
• Degree Day Calculation.
A sample database is available as a supplement to this document and may be used as a guide for configuring
applying these objects.
•
Figure 1
Sample Energy Management objects database open in JDE.
Energy Management Objects Application Engineering Notes
Niagara Release 2.3 Revised: January 2, 2003
1
Sliding Window Demand Calculation
Figure 2
The Energy Management objects may also be found individually in your local library.
Sliding Window Demand Calculation
The SWD simulates a thermal demand meter and calculates the sliding window demand for 5, 15, and 30-minute
demand intervals based on an accumulative pulse counter input. It also calculates the total KWH since last reset
and the hourly and daily KWH values.
The hourly, and daily KWH values can then be logged by a standard analog log object setup to execute
on-trigger only. The SWD object fires the hourly and daily triggers to align the KWH data correctly to actual
clock values.
The pulse input into the SWD object is assumed to be accumulative (not delta pulses) that roll over after reaching
the 16 bit limit (65535).
The SWD object can be configured to reset all the calculated accumulative values on a preset interval such as
at “noon on the first Sunday, every month”.
2
Energy Management Objects Application Engineering Notes
Niagara Release 2.3
Revised: January 2, 2003
Sliding Window Demand Calculation
Notes
Notes
A thermal demand meter measures peak demand using thermal electromechanical components. In proportion to
the rate of electrical consumption over a interval such as 15 or 30 minutes, an element in the meter heats up,
pushing an indicator to a new demand level position. The utility meter will record the highest average interval
rate (KW), which will be billed as the “Demand Charge.” At the end of the billing cycle, peak demand will be
read and the demand will be rest to zero for the start of a new billing cycle. The total consumption (KWH) is
also totalized by the meter to determine the “Usage Charge.”
The sliding window demand calculation object can simulate the thermal demand meter by calculating the
average value over an interval. On a normal update frequency, the KW data from the oldest sample is replaced
by the KW data from the most recent sample. This constant updating of the KW information every scan is called
a “Sliding Window Demand Value.”
The highest “Sliding Window” demand reading may be higher than the utility demand since the calculation
updates average demand every 2 seconds and the utility meter may be resetting on a fixed or discrete 15 or 30
minute interval.
Figure 3
Sliding window demand calculation object example.
The Pulse Gen object simulates the
real world pulse contact commonly
output from the meter. The Pulse
Counter object then takes these on/off
transitions and provides a output
representing a running total.
Link these trigger outputs to
the execute trigger inputs of
the logs to synchronize the
data logging.
Commands
None
Properties
•
•
•
•
•
KWHPerPulse—KWH value per pulse, this value is usually noted on the meter or provided by the power
company. It is how much power each pulse represents.
EnableReset—flag to enable recurring automatic reset
DayOfMonth—day of month for recurring automatic reset
DayOfWeek—day of week for recurring automatic reset
time—Time of day for recurring automatic reset
Energy Management Objects Application Engineering Notes
Niagara Release 2.3 Revised: January 2, 2003
3
Electric Demand Limiting
Inputs
Inputs
•
currentPulseCount—link to pulse counter input object to read running total of pulses
Outputs
•
•
•
•
•
•
•
•
•
•
•
hourTrigger— trigger for link to Hourly Log. Log object must be set to execute on-trigger
dayTrigger— trigger for link to Daily Log. Log object must be set to execute on-trigger
resetTime—time of last reset
Demand5KW—sliding 5 minute demand KW value
Demand15KW—sliding 15 minute demand KW value
Demand30KW—sliding 30 minute demand KW value
KWH—running consumption KWH value since last reset
KWHHourly—running consumption KWH value since last hourly reset
KWHLastHour—consumption KWH value for last hour
KWHDaily—running consumption KWH value since last daily reset
KWHLastDay—consumption KWH value for last day
Electric Demand Limiting
This Program object provides electrical demand limiting. On each new minute, this object predicts a demand
average of a sliding window interval (the length of which is user defined) by combining projected usage with
historical samplings and averaging over the interval. The user controls the assumed position (in percentage)
within the sliding window. The user may divide the day into three sections, each with its own demand limit. The
projected demand is compared to the limit for the current time-of-day to decide whether “shedding” or
“reloading” loads is appropriate in a fixed priority. The time, date and value of new demand limits are saved for
both this month and the previous month.
Notes
This object provides an output that can be linked to the Shed Control objects that actually perform the equipment
control. A message is output with each calculation to provide an indication of the object's calculated result or
recommendation. When reloading from a shed condition the projected demand is must be less than the demand
setpoint by greater than at least the value of the power associated with that shed level. For example if the
property of shed level 1 is assigned a value of 100 KW, it won’t be restored until the projected demand is at least
100 KW less than the setpoint.
Commands
Execution of this object can be enabled or disabled (default) either automatically or manually (via right click).
4
Energy Management Objects Application Engineering Notes
Niagara Release 2.3
Revised: January 2, 2003
Electric Demand Limiting
Properties
Figure 4
Electric Demand Limiting.
These objects simulate the
pulse meter and summation of
those pulses as a total.
The EDL object is linked to the pulse total and
outputs the number of loads to shed based on
the projected demand verses demand setpoint.
These objects respond to the load shed request and are
covered individually latter in this section.
Properties
•
•
•
•
•
•
•
•
•
•
•
billingStartDay—Day that monthly historical values are transferred to last month's values
demandInterval—Length of demand interval (default is 15 minutes)
percentIntervalElapsed—Percent of demand period that is assumed to have elapsed
demandPeriod1Start—Time of the beginning of first demand period
demandPeriod2Start—Time of the beginning of second demand period
demandPeriod3Start—Time of the beginning of third demand period
demandLimitPeriod1—Limit for first demand period determined by demandPeriod1Start
demandLimitPeriod2—Limit for second demand period determined by demandPeriod2Start
demandLimitPeriod3—Limit for third demand period determined by demandPeriod3Start
demandLimitingDeadband—Deadband used in determining whether loads can be restored
powerShedLevel[1-32]—Table for power associated with each shed/reload level
Inputs
powerInput—Linked to the power source representation
• predictionEnabled—Allows manual or automatic enabling/disabling of demand prediction
•
Energy Management Objects Application Engineering Notes
Niagara Release 2.3 Revised: January 2, 2003
5
Output Load Shed
Outputs
Outputs
•
sOut—Linked to Shed Control object (number of levels that should be shed)
Output Load Shed
This program object provides shed control for binary outputs. It can control outputs representing up to 16
contiguous shed levels, starting from a user specified level. This object receives a shed level value (1-32) from
the Electric Demand Limiting (EDL) object which specifies the number of load levels that should be shed. A
secondary link can also be made and used as a backup when the primary shed level is not available. It provides
an output message that indicates this object's state in reference to the overall demand limiting control scheme.
See Figure 4, “Electric Demand Limiting.”
Notes
The shed levels refer to loads that are linked to each shed level output. As the requested shed level input value
increases a corresponding number of shed outputs will change state from auto to false. The output from this
object would then link to the priority array of binary output objects that are actually controlling the loads. The
base level for shedding provides the starting point in the shed level sequence that this shed object will respond
to. For example if the base level for shedding is set to 1, the outputs will correspond to shed levels 1-16. If the
base level for shedding is set to 17, the outputs will correspond to shed level 17-32. Multiple output load shed
objects can be used for maximum flexibility.
Commands
Execution of this object can be enabled or disabled (default) either automatically or manually (via right click).
Properties
•
baseLevelForShedding—Specifies the shed level associated with the first control output (pOut1)
Inputs
shedEnabled—Allows manual or automatic enabling/disabling of shed control
• primaryShedLevel—Linked to Demand Monitoring object (number of levels that should be shed)
• secondaryShedLevel—Linked to Demand Monitoring object (number of levels that should be shed)
•
Outputs
•
6
pOut[1-16]—Linked to equipment that is to be controlled by demand limiting, typically a BO’s priority
array
Energy Management Objects Application Engineering Notes
Niagara Release 2.3
Revised: January 2, 2003
Setpoint Load Shed
Notes
Setpoint Load Shed
The Setpoint Load Shed object will provide the application engineer with an easy method of implementing load
shedding strategies. In response to a link to a shed level output, a linked setpoint will be raised or lowered by a
specific offset depending on wether the mode is heating or cooling. The offset is “added” to the setpoint input
so the offset can be either positive or negative.
See Figure 4, “Electric Demand Limiting.”
Notes
Generally this object solves the problem often found in many temperature control sequences where shutting
down an output directly may be complicated by other control dependencies. By changing the setpoint based on
a shed request, the output is shut down under the direction of the control sequence and the interdependencies are
maintained.
Commands
None.
Properties
•
priorityForWriting—priority at which command is issued
Inputs
•
•
•
•
•
shedInhibit—'false' input causes setpoint to be adjusted by offset
setpointIn—Setpoint input that will be adjusted by this object
htgOffset—Setpoint will be adjusted by this signed (+ or -) amount if active and in heating mode
clgOffset—Setpoint will be adjusted by this signed (+ or -) amount if active and in cooling mode
modeIn—0 = off; 1 = cooling; 2 = heating
Outputs
offsetInEffect—Output to indicate if setpointOut has been adjusted
• setpointOutStatus—Adjusted setpoint if active otherwise passes through original setpoint
• setpointOutPrioritized—Adjusted setpoint if active otherwise passes through original setpoint
•
Energy Management Objects Application Engineering Notes
Niagara Release 2.3 Revised: January 2, 2003
7
Setpoint Offset (Reset) Control
Notes
Setpoint Offset (Reset) Control
This object will apply the offset in proportion to the relative value of the shed level input to the
shedLevelHighLimit and shedLevelLowLimit properties.
See Figure 4, “Electric Demand Limiting.”
Notes
This object receives a shed level value (1-32) from the Electric Demand Limiting (EDL) object which specifies
the number of load levels that it is requesting to be shed. A control setpoint is also linked to this object and gets
reset proportionally based on the EDL input. The as the input shed level increases beyond the shed level low
limit the effective setpoint output is offset in proportion to the shed level high limit. For example, if the mode is
presently cooling, the cooling offset is set to 5 degrees, the shed level low limit is 1 and the high limit is 5. The
effective setpoint will increase 1 degree with each level of shed starting at 1, resulting in a setpoint of 76 degrees
(at level 5 the setpoint would be 80 degrees).
Commands
None.
Properties
shedLevelHighLimit—Shed level for maximum offset
• shedLevelLowLimit—Shed level at which offset begins
• priorityForWriting—Priority at which command is issued
•
Inputs
•
•
•
•
•
•
shedInhibit—'false' input causes setpoint to be adjusted by offset
setpointIn—Setpoint input that will be adjusted by this object
htgOffset—Setpoint will be adjusted by this signed (+ or -) amount if active and in heating mode
clgOffset—Setpoint will be adjusted by this signed (+ or -) amount if active and in cooling mode
modeIn—0 = off; 1 = cooling; 2 = heating
shedLevel—Shed level in effect
Outputs
offsetInEffect—Output to indicate if setpointOut has been adjusted
• setpointOutStatus—Adjusted setpoint if active otherwise passes through original setpoint
• setpointOutPrioritized—Adjusted setpoint if active otherwise passes through original setpoint
•
8
Energy Management Objects Application Engineering Notes
Niagara Release 2.3
Revised: January 2, 2003
Optimized Start Stop
Outputs
Optimized Start Stop
This program uses space temperature, a comfort range and mechanical equipment capacity parameters to
calculate the time in advance of a scheduled event that equipment should be started for the space temperature to
reach the comfort zone or can be stopped yet remain within the comfort zone at the scheduled event time.
The default mechanical equipment capacity parameters are under user control. The actual parameters used for
the start/stop calculation may be programmatically adjusted to reflect an analysis of observed results.
A message is output for each start and stop command and at the completion of each analysis. For each start and
stop command, a trigger output is also activated which could initiate auxiliary control sequences.
Figure 5
Optimized Start Stop.
Starting in Niagara Build 2.301.330 (and later builds).
Right mouse click this object to reset the
runtime / drifttime back to user defined values.
Prior to Niagara Build 2.301.330.
Right mouse click this
object to reset the
runtime / drifttime back
to user defined values.
Actually a Composite
object containing two
Program objects (OSS
and TriggerTime).
Note
As shown in Figure 5 above, the Optimized Start Stop (OSS) program contains multiple objects.
Starting in Niagara build 2.301.330 (and later), the use of a Composite object was dropped. The OSS
Program was also modified to accommodate a condition in which exceptionally long leadtimes resulted
when large heating/cooling factors were multiplied by the difference between the space temperature and
its target comfort limit.
Prior to the 2.301.330 build version, if the optimum start time (calculated by subtracting the calculated
leadtime from the scheduled start time) resulted in a time prior to midnight, the start time comparison
failed—and no advance start occurred (that is, ahead of the normal scheduled start time).
In the build 2.301.330 (and later builds), the OSS program will now start the equipment at midnight if
a pre-midnight start is indicated.
Energy Management Objects Application Engineering Notes
Niagara Release 2.3 Revised: January 2, 2003
9
Optimized Start Stop
Notes
Notes
Operation modes of the updated Optimized Start Stop program are described in the following sections:
Start Time
• Stop Time
•
Start Time
If the space temperature is outside the range defined by the lower and upper comfort limits, the difference
between the space temperature and the closer limit represents the number of degrees the mechanical equipment
must make up during the prestart period. The run-time heating or cooling factors (depending on the direction
the space temperature must move) are multiplied by the temperature differential to determine the number of
run-time minutes required to achieve the comfort limit at occupancy, as defined by the schedule's start time.
When the system's time is later than the schedule's time offset by the calculated leadtime, the optimum start
outputs will be enabled. If the calculated leadtime is so large that an optimum start time prior to midnight is the
result, the optimum start will occur at midnight. It is worthwhile to note that an optimum start will be performed
only for the first scheduled start for the day.
Stop Time
If the space temperature is inside the range defined by the lower and upper comfort limits AND the schedule's
status is active, the difference between the space temperature and one of the limits (depending on the mode)
represents the number of degrees the temperature can drift between the time the mechanical equipment is
stopped and the schedule's inactive event time. The lead-time calculation is similar to the one for Start Time but
using the drift-time heating and cooling factors. As a precaution, the mechanical equipment will not be stopped
prior to the time specified by the object's earliestStopTime property. Optimum stop will be performed for each
of the schedule's inactive events.
Commands
The determination of heating/cooling mode and enabling/disabling of both start and stop optimization can be
done either manually or automatically.
Properties
•
•
•
•
•
•
•
10
upperComfortLimit—Cooling mode target.
lowerComfortLimit—Heating mode target.
dynamicParameterAdjust—Controls whether calculation parameters are programmatically adjusted.
oldParameterMultiplier—Ratio (x:1) of old calculation parameter to observed change rate in
determining new parameter.
earliestStopTime—NO stop command will be issued BEFORE this time.
drifttimePerDegreeCoolingUserDefined—User-defined default minutes per degree space temp
changes when equipment stops in cooling mode.
drifttimePerDegreeHeatingUserDefined—User-defined default minutes per degree space temp
changes when equipment stops in heating mode.
Energy Management Objects Application Engineering Notes
Niagara Release 2.3
Revised: January 2, 2003
Optimized Start Stop
Inputs
•
•
•
•
•
•
runtimePerDegreeCoolingUserDefined—User-defined default minutes per degree space temp changes
when equipment starts in cooling mode.
runtimePerDegreeHeatingUserDefined—User-defined default minutes per degree space temp changes
when equipment starts in heating mode.
drifttimePerDegreeCooling—Minutes per degree space temp changes when equipment stops in cooling
mode.
drifttimePerDegreeHeating—Minutes per degree space temp changes when equipment stops in heating
mode.
runtimePerDegreeCooling—Minutes per degree space temp changes when equipment starts in cooling
mode.
runtimePerDegreeHeating—Minutes per degree space temp changes when equipment starts in heating
mode.
Inputs
•
•
•
•
•
•
•
•
•
controlMode—Determines heating/cooling mode for optimized stop.
parameterResetTime—Signals the object to copy the user-defined drifttime and runtime parameters to
their corresponding namesakes used for actual control.
startEnableDisable—Allows manual or automatic enabling/disabling of optimized start function.
stopEnableDisable—Allows manual or automatic enabling/disabling of optimized stop function.
nextEventValue—Linked to a schedule for the action for next event.
scheduleStatus—Linked to a schedule for the present schedule status.
nextEventTime—Linked to a schedule for the time of next event.
outsideTemp—Linked to outside temperature (for information only).
spaceTemp—Linked to space temperature of area affected by mechanical equipment.
Outputs
startTimeCommand—Optimized start command linked to controlled equipment.
• stopTimeCommand—Optimized stop command linked to controlled equipment.
• startTimeTrigger—Provides link for auxiliary sequences at issuance of start command.
• stopTimeTrigger—Provides link for auxiliary sequences at issuance of stop command.
•
Energy Management Objects Application Engineering Notes
Niagara Release 2.3 Revised: January 2, 2003
11
Outside Air Optimization
Notes
Outside Air Optimization
This object uses the two sets of temperature and humidity inputs to find the air supply with the least amount of
heat. The freeCooling output will be set to auto if outside greater than or equal to inside and set to the property
freeCoolingCommand if outside less than or equal to inside - (abs)thresholdSpan. The user can select
temperature or enthalpy comparisons. There is also a low temperature check to protect against freezing.
Figure 6
Outside air optimization.
Notes
This object is commonly linked to the economizer control sequence to enable free cooling. Free cooling is the
process of bringing in outside air and using that air stream as a cooling source in place of, or to supplement
mechanical cool.
Commands
Set outside air low limit to disable free cooling below a specified setpoint.
Properties
thresholdSpan—Deadband used to prevent toggling
• useEnthalpy—“true” if enthalpy is comparison variable
• freeCooling—CommandCommand to output when free cooling is available
• priorityForWriting—Priority at which command is issued
•
Inputs
•
12
outsideTemp—Outside air temperature
Energy Management Objects Application Engineering Notes
Niagara Release 2.3
Revised: January 2, 2003
Night Purge Control
Outputs
outsideHumidity—Outside air humidity
• insideTemp—Inside air temperature
• insideHumidity—Inside air humidity
• lowTemperatureLimit—User-controlled freeze protection limit
•
Outputs
•
•
•
•
•
•
outsideEnthalpy—Calculated outside enthalpy
outsideEnthalpyString—Formatted string to include BTU/lb
insideEnthalpy—Calculated inside enthalpy
insideEnthalpyString—Formatted string to include BTU/lb
freeCooling—Outputs freeCoolingCommand if free cooling is available otherwise, auto is output
modeString—String describing object's present mode
– “Input error”—bad sensor input
– “Input out of range”—enthalpy equal to or less than zero
– “Free Cooling”—free cooling is available
– “No Free Cooling”—free cooling is not available
– “Low temperature”—outside temperature less than lowTemperatureLimit
Night Purge Control
This object uses the two sets of temperature and humidity inputs to find the air supply with the least amount of
heat when the purgeEnabled input is 'true'. The freeCooling output will be set to auto if outside greater than or
equal to inside and set to the property freeCoolingCommand if outside less than or equal to inside (abs)thresholdSpan. The user can select temperature or enthalpy comparisons. There is also a low temperature
check to protect against freezing.
Energy Management Objects Application Engineering Notes
Niagara Release 2.3 Revised: January 2, 2003
13
Night Purge Control
Notes
Figure 7
Night purge control.
Notes
This object is commonly linked to the economizer control sequence to enable free cooling. Free cooling is the
process of bringing in outside air and using that air stream as a cooling source in place of, or to supplement
mechanical cool. Night purge cycle takes advantage the cooler temperatures at night and provides free cooling
in return for additional fan energy for a fan that normally would be off.
Commands
Set outside air low limit to disable free cooling below a specified setpoint. The purge setpoint also be specified.
Properties
thresholdSpan—Deadband used to prevent toggling
• useEnthalpy—“true” if enthalpy is comparison variable
• freeCooling—CommandCommand to output when free cooling is available
• priorityForWriting—Priority at which command is issued
•
Inputs
purgeEnabled—Object enable/disable
• outsideTemp—Outside air temperature
• outsideHumidity—Outside air humidity
• insideTemp—Inside air temperature
•
14
Energy Management Objects Application Engineering Notes
Niagara Release 2.3
Revised: January 2, 2003
Degree Day Calculation
Outputs
insideHumidity—Inside air humidity
• nightSetpoint—User-controlled temperature setpoint target
• lowTemperatureLimit—User-controlled freeze protection limit
•
Outputs
•
•
•
•
•
•
outsideEnthalpy—Calculated outside enthalpy
outsideEnthalpyString—Formatted string to include BTU/lb
insideEnthalpy—Calculated inside enthalpy
insideEnthalpyString—Formatted string to include BTU/lb
freeCooling—Outputs freeCoolingCommand if free cooling is available otherwise, auto is output
modeString—String describing object's present mode
– “Input error”—bad sensor input
– “Input out of range”—enthalpy equal to or less than zero
– “Free Cooling”—free cooling is available
– “No Free Cooling”—free cooling is not available
– “Low temperature”—outside temperature less than lowTemperatureLimit
– “Night purge disabled”—purgeEnabled is false
– “Setpoint satisfied”—target setpoint was reached
– “Night purge complete”—night purge completed but setpoint was not reached
– “Temperature inhibited”—outside temperature is greater than inside
Degree Day Calculation
This program object will perform the math to calculate and degree days for a particular day.
A degree day is a unit of measure of recording how hot or how cold it has been over a 24-hour period. The
number of degree days applied to any particular day of the week is determined by calculating the mean
temperature for the day and then comparing the mean temperature to a base value of 65 degrees F. The mean
temperature is calculated by adding together the high for the day and the low for the day, and then dividing the
result by 2.
If the mean temperature for the day is, say, 10 degrees higher than 65, then there have been 10 cooling degree
days. On the other hand, if the mean temperature is, say, 5 degrees lower than the mean temperature then there
have been 5 heating degree days.
Energy Management Objects Application Engineering Notes
Niagara Release 2.3 Revised: January 2, 2003
15
Degree Day Calculation
Notes
Figure 8
Degree day calculator.
Notes
None
Commands
None
Properties
None
Inputs
•
tempIn—link to outside air temperature
Outputs
•
•
•
•
•
16
minTemp—minimum temperature value since last reset or last midnight
maxTemp—maximum temperature value since last reset or last midnight
meanTemp—mean temperature value calculated at midnight when the day of week changes
clgDegDays—cooling degree days value for yesterday
htgDegDays—heating degree days value for yesterday
Energy Management Objects Application Engineering Notes
Niagara Release 2.3
Revised: January 2, 2003