Quantifying building energy performance through the development and use of key performance indicators (KPIs) is an essential step in achieving energy saving goals in both new and existing buildings. Current methods used to evaluate improvements, however, are not well represented at the system-level (e.g., lighting, plug-loads, HVAC, service water heating). Instead, they are typically only either measured at the whole building level (e.g., energy use intensity) or at the equipment level (e.g., chiller efficiency coefficient of performance (COP)) with limited insights for benchmarking and diagnosing deviations in performance of aggregated equipment that delivers a specific service to a building (e.g., space heating, lighting). The increasing installation of sensors and meters in buildings makes the evaluation of building performance at the system level more feasible through improved data collection. Leveraging this opportunity, this study introduces a set of system-level KPIs, which cover four major end-use systems in buildings: lighting, MELs (Miscellaneous Electric Loads, aka plug loads), HVAC (heating, ventilation, and air-conditioning), and SWH (service water heating), and their eleven subsystems. The system KPIs are formulated in a new context to represent various types of performance, including energy use, peak demand, load shape, occupant thermal comfort and visual comfort, ventilation, and water use. This paper also presents a database of system KPIs using the EnergyPlus simulation results of 16 USDOE prototype commercial building models across four vintages and five climate zones. These system KPIs, although originally developed for office buildings, can be applied to other building types with some adjustment or extension. Potential applications of system KPIs for system performance benchmarking and diagnostics, code compliance, and measurement and verification are discussed.

Miscellaneous energy loads (MELs) comprise a significant and growing portion of total building energy consumption. However relatively little is known about the products that make up MELs end uses, and MELs are modeled with less granularity than major end uses in energy demand models such as the U.S. Department of Energy's Scout energy efficiency impact analysis tool or the U.S. Energy Information Administration's National Energy Modeling System (NEMS). This paper identifies differences in the way MELs versus major building end uses are modeled, and then reviews potential sources of MELs baseline technology data that could be used to improve their characterization in energy demand models. Case studies of dry distribution transformers, hot water circulation pumps, and Japanese-style automatic bidets are presented to compare and contrast the level of baseline data available for different end uses. We show that there is potential to use data from energy conservation standards and other sources to significantly improve representation of some MELs in energy demand models, while other emerging MELs require further data collection before they can be modeled precisely.

Advanced control strategies are becoming increasingly necessary in buildings in order to meet and balance requirements for energy efficiency, demand flexibility, and occupant comfort. Additional development and widespread adoption of emerging control strategies, however, ultimately require low implementation costs to reduce payback period and verified performance to gain control vendor, building owner, and operator trust. This is difficult in an already first-cost driven and risk-averse industry. Recent innovations in building simulation can significantly aid in meeting these requirements and spurring innovation at early stages of development by evaluating performance, comparing state-of-the-art to new strategies, providing installation experience, and testing controller implementations. This paper presents the development of a simulation framework consisting of test cases and software platform for the testing of advanced control strategies (BOPTEST - Building Optimization Performance Test). The objectives and requirements of the framework, components of a test case, and proposed software platform architecture are described, and the framework is demonstrated with a prototype implementation and example test case.