1. Home
  2. Software Accreditation

1. General Requirements

1.1 Scope

  • The Rating Software must satisfy the requirements contained in this section.
  • The Rating Software shall be capable of modeling at least 50 thermal blocks.
  • The Rating Software shall be capable of modeling at least 15 separate HVAC systems.

1.2 Calculation Methods

The Rating Software shall calculate the annual consumption of all end uses in buildings, including fuel and electricity for:

  • HVAC (heating, cooling, fans, and ventilation);
  • Lighting (both interior and exterior);
  • Receptacles and miscellaneous electric;
  • Service water heating;
  • Process energy uses;
  • Commercial refrigeration systems; and
  • All other energy end uses that typically pass through the building meter.

The Rating Software shall perform a simulation on an hourly time interval (at a minimum) over a one year period (8760 hours) with the ability to model changes in weather parameters, schedules, and other parameters for each hour of the year. This is typically achieved by specifying a 24-hour schedule for each day of the week plus holidays.

Calculating Design Loads

The software shall be capable of performing design load calculations for determining required HVAC equipment capacities and air and water flow rates using accepted industry calculation methods for both the proposed design and baseline building design.

Checking Simulation Output for Unmet Loads

The software shall be capable of checking the output of the energy analysis module for the proposed design to ensure that space conditions are maintained within the tolerances specified (maximum of 300 unmet load hours per year).

Adjusting Capacities

For the baseline building (when applicable), the software shall be capable of modifying capacities, temperatures or flow rates for baseline building HVAC system components resulting in excessive unmet loads hours meeting the criteria, following the procedures in Chapter 2.

Error Handling

The software shall identify error conditions when unmet loads fail to meet the criteria, prevent completion of the rating analysis, and provide information to the user describing the error that has occurred and what steps the user should take to remedy the situation.

1.3 Climate Data

The Rating Software shall perform simulations using hourly values of climate data, such as temperature and humidity, derived from WYEC (Weather Year for Energy Calculation), TMY (Typical Meteorological Year) or CWEC (Canadian Weather for Energy Calculations) climate data.

The Rating Software shall calculate solar radiation on exterior surfaces on an hourly basis from the values of direct normal irradiance and diffuse horizontal irradiance contained in the climate data, taking ground reflectance into account.

1.4 Utility Rates

The Rating Software shall be capable of simulating time-of-use rates and apply both demand and energy charges for each time period of the rate schedule.

1.5 Thermal Mass

The calculation procedures used in the Rating Software shall account for the effect of thermal mass on: loads due to occupants, lights, solar radiation, and transmission through building envelope; amount of heating and cooling required to maintain the specified space temperature schedules; and variation in space temperature.

1.6 Modeling Space Temperature

The Rating Software shall contain a dynamic simulation of space temperature which accounts for:

  • Dynamics in change in heating and cooling setpoint temperatures;
  • Deadband between heating and cooling thermostat settings;
  • Temperature drift in transition to setback or setup thermostat schedules;
  • Temperature drift in periods when heating or cooling capability are scheduled off;
  • Temperature drift when heating or cooling capability of the system is limited by heating or cooling capacity, air flow rate, or scheduled supply air temperature; and
  • Indirectly conditioned thermal blocks, where the temperature is determined by internal loads, heat transfer through building envelope, and heat transfer between thermal blocks.

1.7 Heat Transfer between Thermal Blocks

The Rating Software shall be capable of modeling heat transfer between a thermal block and adjacent thermal blocks.

The Rating Software shall account for the effect of this heat transfer on the space temperature, space conditioning loads, and resulting energy use in the thermal block and in the adjacent thermal blocks.

1.8 Control and Operating Schedules

The Rating Software shall be capable of modeling control and operating schedules which can vary by:

  • The hour of the day;
  • The day of the week; and
  • Holidays treated as a special day of the week.

The Rating Software shall be capable of explicitly modeling all of the schedules specified in Appendix C of this manual.

1.9 Loads Calculation

The loads calculations described in this section relate to the simulation engine and not to the procedure used the design engineer to size and select equipment.

Internal Loads

The Rating Software shall be capable of calculating the hourly cooling loads due to occupants, lights, receptacles, and process loads.

The calculation of internal loads shall account for the dynamic effects of thermal mass.

The Rating Software shall be capable of simulating schedules for internal loads in the form given in Appendix C.

The simulation of cooling load due to lights shall account for:

  • The effect of the proportion radiant and convective heat, which depends on the type of light, on the dynamic response characteristic; and
  • A portion of heat from lights going directly to return air, the amount depending on the type and location of fixture.

Building Envelope Loads

The Rating Software shall calculate heat transfer through walls, roofs and floors for each thermal block, accounting for the dynamic response due to thermal characteristics of the particular construction as defined in the Building Descriptors in Chapter 6.

The calculation of heat transfer through walls and roofs shall account for the effect of solar radiation absorbed on the exterior surface, which depends on orientation, reflectance and emittance of the surface.

The Rating Software shall calculate heat transfer through windows and skylights, accounting for both temperature difference and transmission of solar radiation through the glazing.

Calculation of cooling load due to transmission of solar radiation through windows and skylights shall account for:

  • The angular incidence of the direct beam sunlight and the angular and spectral dependence of the solar properties.
  • Orientation (azimuth and tilt of surface).
  • The effect of shading from overhangs side fins, louvers or neighboring buildings or terrain.

Infiltration

The Rating Software shall be capable of simulating infiltration that varies by the time of day and day of the week.

1.10 Systems Simulation

General

The Rating Software shall be capable of modeling:

  • The baseline building systems defined in Chapter 6,
  • The lighting, water heating, HVAC and miscellaneous equipment detailed in Chapter 6
  • All compulsory and required features as listed in Appendix A and detailed in Chapter 6
  • The capability to model multiple zone systems serving at least 15 thermal blocks.

The Rating Software shall be capable of modeling plenum air return.

Terminal Characteristics

The Rating Software shall be capable of simulating the effect on space temperature and energy use of:

  • Limited capacity of terminal heating devices;
  • Limited capacity of terminal cooling devices; and
  • Limited rate of air flow to thermal blocks.

HVAC Systems and Equipment

The Rating Software shall be capable of simulating the effect on energy use and space temperature in thermal blocks served by the HVAC system, including:

  • Limited heating capacity of an HVAC system;
  • Limited cooling capacity of an HVAC system;
  • Temperature rise of supply air due to heat from supply fan, depending on the location of the fan;
  • Temperature rise of return air due to heat from return fan;
  • Temperature rise of return air due to heat from lights to return air stream; and
  • Fan power as a function of supply air flow in variable air volume systems.

Central Plant Systems and Equipment

The Rating Software shall be capable of simulating the effect on energy use of limited heating or cooling capacity of the central plant system.

If the Rating Software is not capable of simulating the effect of limited heating or cooling capacity of the central plant system on space temperature in thermal blocks dependent on the central plant system for heating and cooling, then it shall issue a warning message when loads on the central plant system are not met.

Equipment Performance Curves

The Rating Software shall be capable of modeling the part load efficiency and variation in capacity of equipment as follows:

  • Furnaces as a function of part load;
  • Boilers as a function of part load, supply hot water temperature, and return hot water temperature;
  • Water-cooled compressors including heat pumps and chillers as a function of part load, evaporator fluid, or air temperature and condensing fluid temperature;
  • Air-cooled compressors including heat pumps, direct expansion cooling and chillers as a function of part load, ambient dry-bulb temperature, and wet-bulb temperature returning to the cooling coil;
  • Evaporative cooling systems as a function of ambient wet-bulb temperature; and
  • Cooling towers as a function of range, approach and ambient wet-bulb temperature.

Economizer Control

The Rating Software shall be capable of modeling integrated air- and water-side economizers.

The Rating Software shall be capable of modeling electronic enthalpy air-side economizer controls that vary the high limit as a function of both temperature and enthalpy.

Air Side Heat-Recovery

The Rating Software shall be capable of modeling heat recovery between the exhaust air stream and the outside air stream. The software shall account for auxiliary energy uses associated with heat recovery systems, including pumping energy, frost control, and system control.

Heat-Recovery Water Heating

The Rating Software shall be capable of modeling heat recovery water heating from the following sources:

  • Double bundled chiller;
  • Refrigerant desuperheater as part of a packaged HVAC unit;
  • Heat exchanger on the condenser water loop; and
  • Heat-recovery water-to-water heat pump operating off of the condenser or chilled water loop.

Heat-Pump Water Heaters

The Rating Software shall be capable of modeling heat-pump water heaters. The algorithm must allow the evaporator coil to be located in:

  • Any thermal block;
  • Any plenum; and
  • Outside.

1.11 Managing User Input

This section addresses the processes of data entry and the validation of user input data that can be performed prior to and independent of the energy simulation.

Building Descriptor Inputs and Restrictions

Building descriptors are discussed in Chapter 6 and listed in tabular form in Appendix A. Building descriptors are classified in one of several ways:

  • Reference. Information that does not affect the energy rating results, such as the name of the architect, the address of the building, or rating authority applications numbers.
  • Trigger. A building descriptor that turns on or turns off the applicability of other building descriptors. An example is the daylight modeling method.
  • Asset. Information about the rated building that does affect the results such as insulation levels, window construction or equipment efficiency.
  • Special Asset. Information about the rated building that is considered an asset, but requires special documentation of performance. Examples include reduced infiltration or credit for natural ventilation.
  • Neutral Dependent. Information that is the same for both the rated building and the baseline building. The baseline building assumes the same conditions specified for the rated buildings. Examples are schedules of operation, temperature settings, etc. For purposes that do not use a modeled baseline building, such as Design to Earn ENERGY STAR, the designation of “neutral dependent” means that the rating process attempts to neutralize for this variable.
  • Use-or-Lose. This is a special case of a neutral dependent classification except that baseline value has a floor or ceiling. An example is retail display lighting whereby the baseline building is equal to the rated building up to a maximum power limit. When the rated building value is within an acceptable range, the use-or-lose” variable is neutral dependent. When the value for the rated building is outside the acceptable range, the building descriptor is an asset.
  • Neutral Independent. Information that is the same for both the rated building and the baseline building, but is prescribed. Examples are schedules of operation when the purpose is federal tax credits.
  • Defaults are provided for many building descriptors. A common default is provided for convenience and may be overridden by the user with no special documentation. However, when a default is provided for a special asset, the value must be used unless special documentation is provided. 

Building descriptors may also be classified by the level of software support that is required: compulsory, required, optional, and unsanctioned. Compulsory inputs must always be supported by the software and specified by the user. Required inputs shall be supported by the rating software but they may not be applicable for all ratings. Optional inputs are addressed in this anual and restrictions may apply, but it is up to the software vendor as to whether the inputs are supported. Unsanctioned inputs are inputs that are not addressed in this manual; these are not listed in Appendix A or discussed in Chapter 6.

Restrictions may apply to all compulsory and required inputs. Appendix A specifies the compulsory building descriptors. Examples of compulsory inputs are climate zone, floor area, and space-by-space classification. If the software provides a means for the user to input building descriptors listed as optional in Appendix A, all input conditions and restrictions shall apply.

The software user interface shall: 1) clearly indicate when a building descriptor has an associated default, 2) indicate what the default value is, and 3) provide a convenient means for the user to over-ride the default. When default values for special assets are overridden, the software interface shall notify the user that documentation is required.

For neutral independent building descriptors, the software is not required to provide a means for users to enter data since the software will automatically assign the prescribed value. However, if the user is permitted to input values for prescribed inputs, the software must inform the user that a prescribed value and not the value input by the user will be used in calculating the rating.

No restrictions are specified for unsanctioned inputs. If the software uses unsanctioned inputs, the software documentation or help system shall specify the applicability of the building descriptors, its definition, the units in which it is expressed, restrictions on input for the proposed design, and, if applicable, how the building descriptor is defined for the baseline building.

The software may assist the user in describing the proposed design by displaying typical values for building descriptors, provided deliberate action by the user is necessary before a displayed value is used.

Data Validation

Compulsory Input Checks

The software shall check to ensure that valid entries have been made for all compulsory building descriptors before the user is permitted to proceed with the next step in the rating process.

Handling of Missing Inputs

If a required input is missing or invalid, the software shall: 1) notify the user that the input is missing or invalid, 2) identify the input field(s) with missing or invalid data, and 3) prevent the user from moving to the next step of the rating process. The software may provide additional information designed to help the user correct the deficiency.

Validity Checks

The software shall check all user inputs to ensure that the following conditions are met:

  • Simulation Tool Limits. Inputs do not exceed the minimums or maximums for the parameters permitted by the simulation engine.
  • Rating Rule Limits. Inputs do not exceed minimums or maximums for the descriptors specified in Chapter 6 of this document.
  • Simulation Tool Discrete Options. Inputs correspond with valid discrete or list options for parameters available in the simulation engine.
  • Rating Rule Discrete Options. Inputs correspond with valid discrete options provided for in Chapter 6.

Handling Invalid Input

When invalid data is entered, the software shall: 1) notify the user of the invalid input, 2) identify the nonconforming input field, and 3) prevent execution of the next step of the rating process; i.e., generating the input description for the proposed design. The software may provide additional information designed to help the user correct the deficiency.

Consistency Checks

The consistency checks described above are intended to identify errors and oversights in user input and thereby help ensure that the building description is complete and interpretable by the energy analysis program. Examples of consistency checks include making sure that total window area does not exceed the wall area in which they are contained and that the necessary plant equipment has actually been connected to the secondary HVAC systems. The software may include additional consistency checks provided these are clearly documented in the user documentation or on-line help system.

Handling Inconsistent Input

If the proposed design fails a consistency check, the software shall: 1) notify the user that an inconsistency exists, 2) identify the specific consistency check that has been failed, 3) identify the inconsistent input fields, if feasible, and 4) prevent execution of the next step of the rating process; i.e., generating the input description for the proposed design. The software may provide additional information designed to help the user correct the deficiency.