Professional Documents
Culture Documents
Energy Management Objects: Application Engineering Notes
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.
Figure 2 The Energy Management objects may also be found individually in your local library.
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.
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
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
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).
The EDL object is linked to the pulse total and These objects respond to the load shed request and are
outputs the number of loads to shed based on covered individually latter in this section.
the projected demand verses demand setpoint.
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
Outputs
• sOut—Linked to Shed Control object (number of levels that should be shed)
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
• pOut[1-16]—Linked to equipment that is to be controlled by demand limiting, typically a BO’s priority
array
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
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
Starting in Niagara Build 2.301.330 (and later builds). Prior to Niagara Build 2.301.330.
Right mouse click this object to reset the Right mouse click this
runtime / drifttime back to user defined values. 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.
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
• 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.
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.
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
• outsideTemp—Outside air temperature
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
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
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
Notes
None
Commands
None
Properties
None
Inputs
• tempIn—link to outside air temperature
Outputs
• 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