Energy and Buildings 36 (2004) 1075–1090
Improving building operation by tracking performance metrics throughout the building lifecycle (BLC) D.T.J. O’Sullivan a,∗ , M.M. Keane a , D. Kelliher a , R.J. Hitchcock b a
IRUSE, Department of Civil & Environmental Engineering, University College Cork, Cork, Ireland b Lawrence Berkeley National Laboratory, Building Technologies Department, USA Received 3 December 2003; received in revised form 19 February 2004; accepted 3 March 2004
Abstract An industry foundation class based building product model of University College Cork’s “to be constructed” Environmental Research Institute will be developed. This paper discusses combining such a building product model with a building management system and other tools and technologies to create a framework for monitoring, analysing and controlling a building throughout its building lifecycle based on a set of performance metrics. The framework will be known as the building energy monitoring, analysing and controlling (BEMAC) framework. Current building performance assessment practices lack standardisation/continuity throughout the building lifecycle. An environment such as the BEMAC framework described in this paper offers a means to achieving such standardisation/continuity by documenting and communicating performance metrics data such that these data can provide value across the complete lifecycle of a building project, from planning through design and construction into occupancy and operation. © 2004 Elsevier B.V. All rights reserved. Keywords: Building performance; Performance metrics; Building product model; Building management system; Industry foundation classes; Building lifecycle
1. Introduction A computer-based building product model (BPM) of University College Cork’s (UCC) “to be constructed” Environmental Research Institute (ERI) [1] will be developed that, together with a building management system (BMS), and other IT tools and technologies, creates an integrated environment allowing for the storage, measurement and control of certain performance-based sustainability criteria in relation to the buildings energy usage (Fig. 1). This paper describes the BEMAC framework that provides a platform for integrating existing software tools at design, construction and operation stages of buildings so that monitoring, analysis and control of performance, with regard to energy usage, at all stages of the building lifecycle (BLC) can be achieved. The future of sustainable buildings lies in such a performance-based approach at all stages of the BLC. Building performance assessment (BPA) is currently very fragmented. There is no continuity to the process of building performance assessment through the building lifecycle. ∗ Corresponding author. Tel.: +353-21-490-2913; fax: +353-21-427-6648. E-mail address:
[email protected] (D.T.J. O’Sullivan).
0378-7788/$ – see front matter © 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.enbuild.2004.03.003
Much work is ongoing in the area of developing building performance frameworks to encourage better assessment practices. These building and facility performance frameworks include ongoing efforts to prepare a comprehensive compendium of building performance models such as the International Council for Building (CIB) Performance Based Building Program [2–4], to the development of a system for assessing the environmental impact of a building over its lifecycle such as the US Green Building Council’s LEED Green Building Rating System [5]. Other frameworks include: the ASTM/Whole Building Functionality and Serviceability [6,7]; the International Code Council (ICC) Performance Code for Buildings and Facilities [8,9]; Building Research Establishment’s Environmental Assessment Method (BREEAM) [10]; and the US Department of Energy (DOE) High Performance Metrics Project [11–13]. Currently however most building performance assessment is done at the design stage of a building through the use of simulation tools, some assessment is carried out at the construction and commissioning stage by means of commissioning tests, but thereafter there is little or no assessment carried out in the operation and maintenance phase of a buildings lifecycle. This despite the fact that current building management systems facilitate trending and archiving of
1076
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
Fig. 1. ERI project overview.
all sorts of data providing a largely untapped resource that can improve the design, operation and energy efficiency of installed systems. Recent case studies [14,15] suggest that energy savings of between 15 and 40% could be made in commercial buildings by closer monitoring and supervision of energy-usage and related data [16]. Fig. 2 sums up the current state of building performance assessment. Performance objectives/criteria related to building energy efficiency are common to all the previously mentioned frameworks, however they often lack quantifiable metrics that can be used to specify and track the energy performance of buildings. Work is also ongoing in this area, which is defining performance metrics that are intended to explicitly represent the performance objectives for a building project using quantitative criteria, in a dynamic, structured format. To be useful across the building lifecycle, each metric must be capable of being either predicted or measured at various stages of the project so that the achievement of the associated objective can be evaluated [17]. Enabling better evaluation of building project objectives will inevitably lead to a
higher level of compliancy with such objectives and hence a greater level of satisfaction with the built environment. Sets of energy-related performance metrics have been defined by various efforts such as: the US DOE HighPerformance Buildings Metrics Project—Performance Metrics related to Resource Consumption and Environmental Loading of Energy Use [12,13]; the ANSI/ASHRAE Standard 105-1984 (RA 99) entitled “Standard Methods of Measuring and Expressing Building Energy Performance” [18]; and as part of the Laboratories for the 21st Century Program, an effort has been undertaken to “develop a standard set of energy performance metrics that will become commonly used in the design, commissioning and operation of laboratories” [19,20]. If such performance metric sets are standardised and associated with the earlier mentioned building performance frameworks, the potential for performance tracking throughout the building lifecycle, given the right Information Communication Technology (ICT) framework/environment, becomes a reality. This paper proposes such a framework based
Fig. 2. Current state of building performance assessment.
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
1077
Fig. 3. BPM used to track metrics throughout the BLC.
around the concept of using a building product model to track performance metrics throughout the building lifecycle (Fig. 3). The building product model offers the link or feedback loop for information exchange throughout the BLC that is currently lacking in building performance assessment practices (Fig. 2). The previous scenario offers a means of documenting and communicating performance metrics data such that these data can provide value across the complete lifecycle of a building project, from planning through design and construction into occupancy and operation. The accumulated archive of data additionally captures a performance history of the project that can be analysed to evaluate the success of various decisions along the way, leading to an overall improvement in the delivery and maintenance of the built environment.
Fig. 4 illustrates a scenario for tracking performance metric data across the lifecycle of a building that could be achieved in the proposed framework. The scenario begins during pre-design planning where an initial set of performance metrics are specified as documentation of the building program. During design, this initial set is elaborated and modified as the design evolves. The results of simulation and other assessment methods are used to update the performance metric data. These assessment results become the benchmarks of expected performance for the final building design. Carried forward to the commissioning phase, these design benchmarks identify both what to measure in the constructed building, and the expected level of performance with respect to each metric. Following commissioning the updated metric data act as as-built benchmarks for use dur-
Fig. 4. Lifecycle performance metric tracking scenario.
1078
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
ing ongoing operations, maintenance, and retrofit of the facility. Comparing these benchmarks to data collected by a building management system can then perform periodic assessment of ongoing performance. This continually updated archive of performance metric data thus serves to support numerous activities across the building lifecycle [17]. With an archive of building performance data, it is now possible to assess how well the simulation tools, initially used to assess design decisions, are emulating what is actually happening in the occupied building. Inevitably there will be discrepancies due to assumptions made within the simulation tools, for example the assumed equipment schedules may be inaccurate. By adjusting such assumptions the simulation tool can now be calibrated to better model the real situation. Such a calibrated model could now be employed to test changes to the design or operation of a building to improve its performance. Use of analysis/simulation tools at later stages of the building lifecycle is an area of much research in recent times [16,21–25]. This paper will discuss the concept of performance metrics and objectives. The paper also describes the standards, tools and technologies employed in developing an extensible environment to implement the proposed BEMAC framework and the associated methodologies. It also examines the architecture behind tying these various tool and technologies together. The paper then demonstrates a sample implementation whereby the performance metric “energy use of a fan” is tracked, and the results are visualised on a 2D plot. Finally the paper discusses how this work can be advanced upon to ensure improvements in building performances.
2. Performance metrics and objectives 2.1. The methodology A building project begins with a consideration of the various performance objectives of interest to building stake-
holders (e.g. owners, designers, operators, occupants, etc.). While primary attention is generally given to space requirements and construction costs, a wide spectrum of objectives may be at least informally considered at this stage, including: energy-efficiency; environmental impact; lifecycle economics; occupant health, comfort and productivity; and building functionality, adaptability, durability and sustainability. The process of elaborating on the objectives for a given building project is often referred to as programming. The intent of programming is to define the desired performance for a facility so that design and operation decisions can be made to achieve this performance. The outcome of programming is most commonly recorded in freeform text that becomes part of design and construction documentation. This documentation may be frequently referenced during design, and occasionally referenced during construction, but then most often is lost from that time forward. Performance metrics can be used to more clearly and quantitatively define the performance objectives for a building [17]. One or more performance metrics may be identified for any given performance objective that building process participants wish to specify and track. A guiding principle in selecting a performance metric is to identify a critical variable that measures, reflects, or significantly influences a particular performance objective. For example, a high-level performance objective may initially be identified using only a qualitative statement such as the desire to “optimise energy performance” in a building. In order to assure the achievement of an objective statement like this, it is helpful to elaborate it using multiple metrics that influence its overall satisfaction. This elaboration can be organised hierarchically. The hierarchy in Fig. 5 shows one possible subset of performance metrics that could be used to specify, track, and maintain energy-efficiency in a building [17]. The performance objectives for a building, and their constituent metrics, often change as a project moves through time. Objectives become more fully elaborated and are modified as conflicts are discovered and resolved. Similarly, ad-
Fig. 5. Performance objectives and metrics hierarchy.
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
1079
EnergyPlus Simulating Performance
Jan Dec
Performance Metric
Dec
Jan Jan Dec
Ventilation System Energy Use
Metric Benchmark Simulated Metric Assessment Measured Metric Assessment
BPM1 BPM2
BPM3
BPM4
BPM5
BPM0
Specification
Design
Construction & Commissioning
14/02/2003 ..14.30
14/02/2003 14.45
14/02/2003 15.00
14/02/2003 15.15
Operation & Maintenance
The Building Lifecycle Fig. 6. Tracking of a specific performance metric.
ditional performance metrics may be identified, their desired performance levels (benchmarks) may change, and the actual performance of a building will vary over time. A building product model for tracking performance metrics must therefore be capable of archiving a history of these changes across the lifecycle of a building [17]. Developing a building product model that successfully achieves this will enable unprecedented tracking of performance metrics throughout the building lifecycle. 2.2. The goals As an example consider a building that is in its operational phase, one could elicit a specific performance metric from the BPM to evaluate that individual metrics performance over the entire BLC. Results could be illustrated on an x–y plot where the y-axis represents the specific performance metric, say ventilation system energy use, and the x-axis represents the metrics transition through the phases of the BLC. One might expect to get a plot along the lines of Fig. 6. To explain some features of the above plot; firstly it is notable that a number of instances/versions of the building product model are produced, however all these BPMs represent the same building at different stages of its lifecycle and they all reside in a single central database. Essentially a new BPM instance needs to be produced for each major design change, so in the above BPM 0 is merely
a specification mainly consisting of goals and objectives. BPM 1 is a more detailed design using CAD and simulation tools to produce geometrical data and expected levels of performance, as are BPMs 2 and 3. The design typically changes between these BPMs to better facilitate the achievement of particular objectives. BPM 4 is built on from BPM 3 but will also contain all construction (as built) data such as material data and commissioning test results, which will be used to update the performance metrics and objectives. Finally the ultimate BPM 5 is built on from BPM 4 but now also contains operational data from the building’s BMS. Another point of note in the above is that simulations do not start until BPM 1 is produced because a somewhat detailed design is necessary to carry out a simulation. Furthermore simulation metrics for particular designs are carried out over hypothetical years. Benchmark metrics come from basic simulations or databases of expected performance for particular building types. Measured metrics come from commissioning tests for the construction and commissioning stage and are retrieved by the BMS for the operational stage of the building lifecycle. Finally, clearly there will only be measured data for the construction and commissioning and operation phases. Time steps for the operation phase can be varied, 15 min intervals are shown above. Fig. 7 further clarifies the process of events and demonstrates how the central data repository captures the building
1080
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
Fig. 7. The central data repository contains a number of BPM instances.
at all stages of the BLC. Furthermore it provides explicit connections between each of the phases, this facilitates comparisons between the different types of metrics (benchmark, simulated and measured) representing a particular metric value over the course of the BLC. Having established the need for and demonstrated the use of an integrated environment for obtaining, formatting, storing, retrieving and controlling the data associated with the buildings energy usage, an Information Communication Technology framework for its implementation must be decided upon. For the resultant BEMAC framework to be useful it should be extensible and applicable to other buildings in the future, thus it is essential that it comply with the principals of standardisation and open systems. Among such standards employed were the standard for the exchange of product model data (STEP) [26] and industry foundation classes (IFCs) [27] for the transfer of data between the building product model and the various analysis and design tools that communicate with the BPM. To develop the BPM itself, the centrepiece around which the BEMAC framework has been built, an industry standard tool known as Express Data Manager 4.5TM (EDM) [28] was used. The following section specifies how these various tools; technologies and standards combine to give a generic solution, applicable to any building.
3. The framework architecture The technologies central to the creation of an open, generic and extensible environment have been listed. Fig. 8 demonstrates how to join these elements to create a framework applicable to any building that adheres to these open standards.
First and foremost with regard to this BEMAC framework the building product model takes a central pivotal role. In this the building is modelled using the industry foundation classes (IFCs). The database is initially set-up using the EDMsupervisorTM , which allows the creation of a new database using a graphical user interface (GUI). Then the underlying schema (IFC2×), which will be used as a basis for model development, is imported. Again this is achieved using EDMsupervisor’s GUI and importing an express file that defines the entire IFC2× specification. The database now “knows” the rules and constraints that its model must adhere to. Now the database needs to be populated in accordance with the underlying schema and this introduces the first of the tools that needs to communicate with the EDM building product model, namely ArchiCADTM developed by Graphisoft. ArchiCADTM is a 3D CAD tool [29] and was chosen for this implementation ahead of other 3D CAD tools such as Bentley’s Micostation TriFormaTM [30], or AutoDesk’s Architectural DesktopTM [31], because it is well advanced with regard to its compliancy with the IFC schema. It was IFC2× compliant ahead of most/all other 3D CAD tools. When designing in ArchiCADTM , a model of the real building is created. Instead of drawing lines, ellipses and arcs, one raises walls, adds windows and doors, lays down floors, builds stairs and constructs roofs. Most importantly from this research point of view ArchiCADTM is able to export this information, in accordance with the IFC specification, in the form of a standard STEP physical file (P-21 file). Thus given the design of the Environmental Research Institute (ERI) developed in the ArchiCADTM tool, the EDMdatabaseTM can be populated by importing the P-21 file generated by ArchiCADTM such that the EDMdatabaseTM now contains an IFC compliant virtual building (building
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090 CONTROLLING TOOL
MONITORING TOOL
1081 ANALYTICAL / DESIGN TOOLS
SENSORS / SWITCHES BMS Front-End
BMS Controller
Programming application to elicit data required by IFC (resides in controller)
C++ program to input data obtained from sensors into EDM DB.
EDM DATABASE Building Product Model
C++ applications to communicate with the various packages eg. Energy analysis tools etc. This data can take the form of Express files, csv’s, P-21 files, XML files and more.
Energy Analysis & Simulation Tools e.g. EnergyPlus TRNSYS
Comfort Analysis Tools e.g. CFX
CAD packages e.g. ArchiCAD AutoCAD
Future Tools e.g. Prediction Tools
Fig. 8. The BEMAC environment.
Fig. 9. Transition from 3D CAD model to P-21 file and into database.
product model) (Fig. 9). It is important to point out that this process is not quite as simple and straight forward as suggested in Fig. 9 and the designer, using ArchiCADTM to develop the model, needs to appreciate certain aspects of the compilation process from ArchiCADTM to P-21 file, such that this transition occurs in an apparently seamless manner. Initially this building product model will consist mainly of geometrical and material data. In the next section, on implementation of the framework, it will be shown how
this initial model is extended to accommodate the notion of performance metrics and objectives as proposed in this paper. With the geometric building product model now in place, the operation, control and monitoring of the ERI building are the next considerations. Data elicited from the building management system, must now be tied in with the IFC compliant BPM. In Fig. 8 the sensors/switches represent the various types of building automation controllers distributed
1082
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
throughout the Environmental Research Institute. These are networked in accordance with a standard building controls protocol such as BACnetTM [32], and controlled by the BMS controller, which sends messages, runs routines etc. A facilities manager using the BMS front-end, with its associated graphical user interface, can in turn edit/program this controller. The controller can therefore be set up such that particular values, required by the central BPM, for instance various performance metrics, are elicited from the BMS at certain intervals. Using the programming implementation method of EDMinterfaceTM , these data values can now be passed into the BPM. This programming can be implemented in any of the following programming languages; C, C++, JAVA, or VB. C++ was chosen for a number of reasons. First and foremost it is an object-oriented programming language. This ties in well with the object-oriented IFC schema and object-oriented BPM, such that there is a seamless integration between the software engineering phases involved in the project, right through to implementation and maintenance. Secondly, C++ is well developed, tested and supported within the EDM environment. This programming method of implementing EDMinterfaceTM is the method by which most of the analytical/design tools communicate with the BPM at regular intervals during operation of the building. By automating this process it reduces the need for management of the BPM. Samples of these programs will be illustrated in the following section on implementation. Finally with respect to the other tools that will communicate with the building product model these include energy analysis and simulation tools, e.g. EnergyPlusTM and TRNSYSTM [33,34], to carry out tasks such as monitor the building’s energy usage, comfort analysis tools, e.g. CFXTM [35], to carry out a CFD analysis and any other tools that need to communicate with the BPM. The easiest way for this communication to occur is if the particular software tool talks the STEP compliant IFC language. This last statement highlights the benefits of open standards once again. Because the BPM has been developed in accordance with the IFC standard the onus is primarily on the architectural, engineering, construction and facilities management (AEC/FM) industry software developers to make their tools IFC compatible, such that those tools can become a part of this encapsulating framework. However in this implementation, because of the extensive functionality offered by Express Data Manager 4.5TM , even tools that are not IFC compliant can talk to the building product model by parsing the data repository with an applicable C++ program, that either retrieves the data required by that tool from the BPM or stores the data obtained from that tool into the BPM. This is made possible due to the range of formats in which EDM can accept data. None the less, IFC compliancy is most definitely the way forward for AEC/FM industry software developers enabling direct communication without the need for any intermittent parsing programs.
4. Implementation/results Although as earlier described this is a framework to enable monitoring of performance metrics over the entire building lifecycle, for the purpose of this research an existing building is being used as a prototype and thus the operational phase of the BLC is the focus of attention. Hence with regard to Fig. 6, it is the BPM 5 instance of the BPMs that will be produced. The building used for this research is the Mardyke sports arena in University College Cork (UCC). This is an 18.5 million, 6511 m2 indoor sports complex located just off the main campus on the banks of the river Lee in the Mardyke area of Cork city. It is made up of a six-lane, 25 m swimming pool, a 1400 m2 sports hall, a 425 m2 main fitness suite, along with offices, meeting rooms, performance laboratories, dance studios, catering facilities and a second newly created overflow fitness suite. This building is similar in size to the proposed ERI building and more importantly both buildings require quite strict climate control with regard to their HVAC systems. As a sample performance metric that forms part of the ventilation system energy use metric shown in Fig. 6, the energy consumption of a supply fan in one of the AHUs will be considered for this paper to demonstrate the implementation behind producing a plot along the lines of Fig. 6. The process of producing this plot is quite complex and requires a good understanding of the BEMAC framework at a number of levels. For instance, one must understand: how to control or program the building management system to elicit the necessary data; how to extend/instantiate certain areas of the IFC schema such that it can archive data and accommodate performance metrics; how to develop programs to input data to and elicit data from the correct locations in the database; and finally how to combine these programs with plotting programs to illustrate the results. The following sections will elaborate on each of these tasks. 4.1. Eliciting data from the BMS The building management system in the Mardyke sports arena was created by Cylon Controls [36] and installed by ACE Controls Systems Ltd.1 It comes with a relatively easy to use graphical user interface. For this sample case where the performance metric of interest is the supply fan energy consumption, the reading from the BMS of interest is the supply fan variable speed drive (VSD) signal, which is a percentage reading representing the fan speed. From this value one can determine the frequency of the fan, and thereafter by using the correct fan curve, the current used by the fan. Given this information the energy consumption of the fan is easily deduced. By simply ticking the value of interest as shown in Fig. 10, one can relatively easily set up the BMS
1 ACE Controls Systems Ltd., Unit 7, Ballincollig Enterprise Park, Link Road, Ballincollig, Co. Cork.
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
1083
Fig. 10. The BMS graphical user interface.
such that it archives the values required in the form of a comma separated variable (csv) file to a certain location at a specified frequency. Later it will be shown how the Express Data Manager 4.5TM storage program then retrieves this csv file and stores the data in its correct location in the database. 4.2. Instantiating the IFC schema Because the IFC schema is so vast, AEC/FM software developers will typically instantiate the so-called “views” of the schema. That is to say they will develop their software in accordance with the area of the IFCs that is most relevant to their particular industry. Hence taking ArchiCADTM for instance, that is initially used to populate the database via a P-21 STEP file, while ArchiCADTM implements nearly all the architectural features of IFC, it might not for instance implement/instantiate an IfcSensor since this is more in the facility managers domain of interest. Likewise ArchiCADTM does not implement performance metrics and objectives even though they have been part of the IFC schema since Version 2.0. However as explained earlier the schema underlying the building instantiation is the entire IFC2× schema, thus it is possible to instantiate the performance metrics and objectives part of IFC and tie them into the initial building product model as created by the P-21 file generated by ArchiCADTM . This is achieved through a C++ program and a good understanding of the IFC2× schema knowing what to create and where to tie it in with the initial BPM. Fig. 11
is a simplified view of the objects that need to be created to instantiate the performance metric and objective parts of the IFC schema. This illustrates the complexity in adding and connecting performance metric and objective data to a single supply fan object. In respect to the above, the C++ program newly creates all the elements other than the initial existing supply fan object. The program consists of several pages of code, and loops through all the objects in the building product model. If the object will have performance objectives and metrics data associated with it at a later stage, the program instantiates the necessary objects to create spaces for such data to be stored. Now new positions exist in the database for the Express Data Manager 4.5TM storage program to input the data from the respective csv files. With regard to Fig. 11 it shows there are three types of metric data as was also illustrated in Fig. 6 earlier. Table 1 suggests where the data for each respective metric type might come from for the sample performance metric, the fans energy consumption.
Table 1 Source of data values for metric, “energy consumption of a fan” Metric type
Benchmark metric
Source of data Manufacturers catalogue
Simulated Measured assessment metric assessment metric EnergyPlus simulation
BMS
1084
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
Fig. 11. Instantiating performance objectives and metrics in IFC.
4.3. Extending the IFC schema The IFC2× release of the IFC data model used in this research is primarily concerned with the exchange of building geometry. IFC2× includes only rudimentary definitions of HVAC equipment, systems and components. The limitations of the HVAC component definitions in the IFC2× data model release made it impossible to exchange rich data sets with HVAC content. This prompted the launching of the BS-8 (BS-8 is the designation for the IAI “Building Services project number 8”) project in 2001 to complete the IFC HVAC domain schemata and make such exchanges possible [37]. This project has since been completed and a major extension to the HVAC part of the International Alliance for Interoperability’s (IAI) IFC data model has been defined, reviewed and implemented, and is now part of the latest IFC release, IFC2×2. This extension facilitates interoperability between energy simulation programs, such as EnergyPlus, and other software used in the design and operation of HVAC systems. The work includes the development of a generic model structure that provides for both product types, as defined in manufacturers catalogues, and individual instances of those types, each of which has a unique placement, connections and performance history. A time series model has been defined to support both the performance histories of individual components and the various boundary conditions—weather data, occupancy schedules, etc. required by simulation tools [38]. Unfortunately with this work being based on the IFC2× model, it is unable to take advantage of the enhancements
made to the IFC data model in the IFC2×2 release. These enhancements will however be incorporated into later versions of the BEMAC framework by using IFC2×2 as the underlying schema for the EDM building product model. However for the purpose of this work there is no “ready-made” mechanism by which to archive performance history data. The archiving of this performance history data is vital in order to reap the benefits earlier described with regard to tracking performance metrics over a building’s entire lifecycle. With this in mind it is important to realise the following with regard to the IFC2× schema; in the schema’s implementation of performance metrics and objectives there exists one place for a measured metric value and one place for a simulated metric value, as can be seen in Fig. 11. However in the proposed framework, for the operational phase of a building lifecycle, these values will be frequently updated. Because there is a need to archive these values it leaves two options: 1. Create a new instance of the BPM each time these values are updated. 2. Devise a method within the bounds of the IFC2× schema by which when these values are updated the overwritten values are archived within the same BPM instance. The first of these options is very wasteful in terms of memory usage since the same data (BPM) is being repeatedly stored with only very minor changes from the previous instance. Hence the second of the options was investigated. The method devised essentially archived the simulated and measured metric values by putting them into IfcComplexProp-
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
1085
Fig. 12. Clip of program that stores and archives metric values.
Fig. 13. Schematic of how archiving is achieved.
erty objects, named by a timestamp and distinguished as simulated/measured. Thus as each value, for example a measured metric value from the building management system comes into the EDM database, as well as being placed in its correct location in the database, it is also placed in a suitably named IfcComplexProperty object. This IfcComplexProperty object is then associated with the relevant object, for instance the supply fan object, through an existing relationship object. Again this required a good understanding of the underlying schema and was all carried out via a C++ program. A tiny snippet from this program is shown in Fig. 12. Essentially, in simplified terms, the results as depicted in Fig. 13, with the archiving IfcComplexProperty object being tied to the object in question, in this case a supply fan. With this method of archiving performance metrics in place, one can understand how in Fig. 6, a single instance of the BPM can cover the entire operational phase of the building lifecycle, or at least until some major renovation/restoration takes place. 4.4. Developing programs to store/retrieve data to/from the BPM Again with regard to developing these programs it is all down to understanding the underlying schema and
knowing how to track down from a high level object such as the root of an IfcBuildingElementProxy representing a supply fan object, down to its associated properties such as the performance metric representing its energy consumption. Fig. 14 illustrates how nested such data can be. Furthermore Fig. 15 is just one function in the program necessary to work down through the numerous objects shown in Fig. 13. For the shown function one is at the point where they have got the correct IfcBuildingElementProxy and are going from there to the IfcMetricValue. 4.5. Plotting your results Finally the programs developed in the previous section need to work with a plotting program to produce graphs such as that in Fig. 6. For this project the plotting program was developed in Microsoft Visual C++ using Microsoft Foundation Classes (MFCs). The benefits of using MS Visual C++ for the plots was that it allowed all the programming from, data retrieval from the EDM database, to data plotting, to be carried out in a single environment. The resulting program is quite long and quite complex and uses all the elements previously described. In the example case, that is, energy usage of a supply fan, the program produces the plot
Fig. 14. Schematic of how metric values are connected to relevant objects.
1086
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
Fig. 15. Function for getting the metric value associated with a particular IfcBuildingElementProxy object.
Fig. 16. Plot of energy use for fan.
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
as in Fig. 16 for a user specified period of the operational phase of the building lifecycle.
5. How such a framework can be used to improve building performance across the building lifecycle The BEMAC framework can improve building performance over the entire building lifecycle. From the design stage the framework can be employed to focus attention on issues such as energy usage. Moving on to the construction and commissioning stage the BEMAC framework can provide expected performance benchmarks against which to commission. This leads to the operation and maintenance stage as was demonstrated in the previous section on implementation. As earlier suggested, Fig. 16 shows there are discrepancies between what the simulation tool expects the performance to be and what the monitored values say it actually is. This would in fact be true for many of the performance metrics. These discrepancies could be due to any one of a number of reasons: components not performing as they should; incorrect assumptions made within the simulation tool (EnergyPlus in this case) etc. The next logical step is to try and calibrate the EnergyPlus model to more closely emulate the real situation. This could be achieved by altering various assumptions made when using EnergyPlus, such as the buildings occupancy schedule. After such calibration Fig. 6 may now look along the lines of Fig. 17. In Fig. 17 the calibrated EnergyPlus model is much more closely modelling the real situation (i.e. what is actually happening). With the calibrated model, one can now look at
the possibility of using EnergyPlus at the more untraditional phase of operation and maintenance of the buildings lifecycle. One can now test changes to the design or running of a building or changes to its HVAC system to see what adjustments will get the building running closer to its intended performance objectives (metric benchmarks). This could in turn lead to a plot along the lines of Fig. 18. Now not only are the measured and simulated metric values in close agreement but more importantly the building is operating very close to its metric benchmarks. This, now very accurate model, offers a very detailed (at both time step and system/equipment levels) measure against which to compare day-to-day building performance as an evaluation of the success of design decisions. This closes the lifecycle loop by providing feedback from operation to design. Finally this model also offers a good basis from which to experiment with the ideas of fault diagnosis and predictive control, areas of much research in recent times [21–25,39,40].
6. Future enhancements The work described in this paper offers a basis for further research and development of the ideas put forward. Firstly one could review the possibility of tying this work in with one of the frameworks mentioned in Section 1, to give them the quantitative basis and implementation procedure they currently lack. Furthermore one could look at the possibility of developing a standard template/procedure for documenting specifications. Pre-design planning should ideally lead Calibrated EnergyPlus Simulating Performance
EnergyPlus Simulating Performance
Jan Dec
Performance Metric
Dec
Jan Jan Dec
Equipment Energy Use
Metric Benchmark Simulated Metric Assessment Measured Metric Assessment
BPM1 BPM2
BPM3
BPM4
BPM5
BPM0
Specification
Design
1087
Construction & Commissioning
Operation & Maintenance
The Building Lifecycle Fig. 17. Tracking of a specific performance metric after model calibration.
1088
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
Calibrated EnergyPlus Simulating Performance
EnergyPlus Simulating Performance
Design Change (as recommended by calibrated model)
Jan Dec
Dec
Jan Jan Dec
Performance Metric Equipment Energy Use Metric Benchmark Simulated Metric Assessment Measured Metric Assessment
BPM1 BPM2
BPM3
BPM5
BPM4
BPM6
BPM0
Specification
Design
Construction & Commissioning
Operation & Maintenance
The Building Lifecycle Fig. 18. Changing design or operation as advised by calibrated model.
to a clear specification of the performance expectations for a new or to-be-renovated building. This process begins with identification of general qualitative performance objectives, but should lead to quantitative performance metric benchmarks that will guide subsequent design and operation decisions. Another extension of this work could be to use the calibrated model as an energy-benchmarking tool like ARCH [41], Cal-Arch [42] and the Labs 21 BDT [43]. Such tools can be used to determine a benchmark whole-building energy use intensity (EUI) that would achieve the desired level of performance for a new building of a given type in a given location, relative to the existing building stock (e.g. a 75th percentile ranking) [16]. Furthermore benchmarks for all key energy-related performance metrics could be determined using the calibrated model. Finally with regard to the Environmental Research Institute, the building for which this framework will be put to the test, the aim is to monitor many more performance metrics than have been monitored in the prototype building. This will effectively lead to a real time database of all the buildings performance metrics, when the building is up and running. As mentioned such a database captures a performance history of the project allowing for evaluation of the success of design decisions. Furthermore this database paves the way for other areas of research such as the idea of predictive control and fault diagnosis. Much work is on going in these areas [21–25,39,40] and the proposed building product model would most certainly offer a good basis from
which to tie these areas in with the framework developed in this research.
7. Conclusions Current building performance assessment practice lacks continuity throughout the building lifecycle. There is a concentration of assessment at earlier stages of the BLC with little or no assessment at the later stages of operation and maintenance. The BEMAC framework developed in this research encourages a continuity in the assessment process throughout the BLC by combining the data from the different phases of the BLC in a single central data repository. Performance metrics can be used to more clearly and quantitatively define the performance objectives for a building. Documenting and communicating performance metric data can provide value across the complete lifecycle of a building project, from planning, through design and construction, into occupancy and operation. A single database processing geometrical, material and real time data offers huge potential for analysis and more. The accumulated archive of data in the proposed building product model captures a performance history of the project that can be analysed to evaluate the success of various decisions along the way, leading to an overall improvement in the delivery and maintenance of the built environment. The wealth of data that the building product model offers in a fully monitored building provides the basis for: im-
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
proving building performance; developing predictive control routines and implementing fault diagnosis measures. Finally the BEMAC framework will in time lead to better more accurate design decisions with regard to, for instance, the sizing of equipment for HVAC systems, by focusing attention on the achievement of performance objectives from an early stage of the design.
Acknowledgements The authors would like to acknowledge the financial support of the Higher Education Authority Programme for Research in Third Level Institutions administered by the HEA in Ireland. We would also like to thank Cylon Controls Limited (Clonshaugh Industrial Estate, Clonshaugh, Dublin 17, Ireland), ACE Controls Systems Ltd. (Unit 7, Ballincollig Enterprise Park, Link Road, Ballincollig, Co. Cork) and UCC’s Buildings and Estates Office (University College Cork, Cork, Ireland) for their contributions during the course of the research. This work has also been supported by The California Energy Commission (Public Interest Energy Research Program, Contract No. 400-99-012); The US Environmental Protection Agency (Climate Protection Division); and The Assistant Secretary for Energy Efficiency and Renewable Energy (Office of Building Technology, State and Community Programs of the US Department of Energy, Contract No. DE-AC03-76SF00098). References [1] Environmental Research Institute, 2002. http://eri.ucc.ie. [2] International Council for Building (CIB), Performance Based Building Program. http://www.cibworld.nl/pages/begin/Pro3.html. [3] G.C. Foliente, CIB, Performance Based Building Program, 2000. http://www.cibworld.nl/pages/begin/Comp.pdf. [4] G.C. Foliente, R. Becker, CIB PBBCS Proactive Programme—Task 1, Compendium of Building Performance Models, CSIRO Building, Construction and Engineering, Victoria, Australia, 2001. [5] US Green Building Council, LEED, Leadership in Energy and Environmental Design Program, 2003. http://www.usgbc.org/ LEED/LEED main.asp. [6] ASTM, ASTM Standards on Whole Building Functionality and Serviceability, 2nd ed., ASTM, International, West Conshohocken, PA, 2000. http://www.astm.org/. [7] G. Davis, F. Szegeti, Introduction to the Standards on Whole Building Functionality and Serviceability, International Centre for Facilities, Ottawa, Ont., Canada, 1999. [8] International Code Council. http://www.iccsafe.org/. [9] ICC, Final Draft ICC Performance Code for Buildings and Facilities, International Code Council, Falls Church, VA, August 2000. http://www.iccsafe.org/codes/iccpc/perf.pdf. [10] BREEAM, Building Research Establishment’s Environmental Assessment Method, 2003. http://products.bre.co.uk/breeam/index.html. [11] US DOE, High-Performance Building Metrics Project, US Department of Energy, Washington, DC, 2003. http://www.eere.energy.gov/ buildings/highperformance/performance metrics/. [12] US DOE, High-Performance Building Metrics Project Framework, US Department of Energy, Washington, DC, 2002. http://www.nrel. gov/buildings/highperformance/metrics/pdfs/framework.pdf.
1089
[13] US DOE, DRAFT—Resource Consumption and Environmental Loading of Energy Use (breakout group meeting notes from Spring 2002 Workshop), US Department of Energy, Washington, DC, 2002. [14] P. Herzog, L. LaVine, Identification and quantification of the impact of improper operation of midsize Minnesota office buildings on energy use: a seven building case study, in: Proceedings of the ACEEE 1992 Summer Study on Energy Efficiency in Buildings, vol. III, ACEEE, 1992. [15] D. Claridge, J. Haberl, M. Liu, J. Houcek, A. Athar, Can you achieve 150% predicted retrofit savings? is it time for re-commissioning, in: Proceedings of the ACEEE 1994 Summer Study on Energy Efficiency in Buildings, vol. V, ACEEE, 1994. [16] T. Salsbury, R. Diamond, Performance validation and energy analysis of HVAC systems using simulation, Energy and Buildings 32 (2000) 5–17. [17] R.J. Hitchcock, High-Performance Commercial Building Systems Program, Element 2-Project 2.1, Task 2.1.2, Standardized Building Performance Metrics, Final Report, Lawrence Berkeley National Laboratory, October 2002. [18] ANSI/ASHRAE, Standard 105-1984 (RA99), Standard Methods of Measuring and Expressing Building Energy Performance, ASHRAE, Atlanta, GA (co sponsored by American National Standards Institute), Washington, DC, 1999. [19] Labs21, Labs for the 21st Century, 2002. http://labs21.lbl.gov/. [20] LBNL/Labs21, DRAFT Proposal 12/15/01Rev1.1—Laboratory Energy Performance Metrics, Lawrence Berkeley National Laboratory A-Team, Berkeley, CA, 2001. [21] J. Clarke, J. Cockroft, S. Conner, J.W. Hand, N.J. Kelly, R. Moore, T. O’Brien, P. Strachan, Simulation-assisted control in building energy management systems, Energy and Buildings 1449 (2002) 1–8. [22] G. Augenbore, C. Eastman, Needed Progress in Building Design Product Models, White Paper, College of Architecture, College of Computing, Georgia Institute of Technology. [23] R. Lahrech, P. Gruber, P. Riederer, P. Tessier, J.C. Visier, Development of a testing method for control HVAC systems by emulation, Energy and Buildings 1447 (2002) 1–9. [24] J.L.M. Hensen, R. Lamberts, C.O.R. Negrao, A view of energy and building performance simulation at the start of the third millennium, Energy and Buildings 34 (2002) 853–855. [25] P. de Wilde, G. Augenbroe, M. van der Voorden, Energy system simulation in performance-based building design, in: Proceedings of the Sixth International Conference on System Simulation in Buildings, University of Liege, Belgium, 16–18 December 2002. ISBN 2-930322-55-1. [26] STEP Tools Inc., Introduction to STEP, 2002. http://www.steptools. com/library/standard/introduction to step.html. [27] Industry Foundation Classes, 2002 http://cig.bre.co.uk/iai uk/iai/page5.htm. [28] Express Data Manager 4.5TM , 2002. http://www.epmtech.jotne.com/ newsletter/ew101/edm45.html. [29] Graphisoft ArchiCADTM , 2002. http://www.graphisoft.com/products/ architecture and design/graphisoft archicad/. [30] Bentley’s Micostation TriForma, 2003. http://www.bentley.com. [31] Autodesk’s Architectural Desktop, 2003. http://www.autodesk.co.uk. [32] BACnet—A Data Communication Protocol for Building Automation and Control, 2002. http://www.bacnet.org/. [33] EnergyPlus, A New-Generation Building Energy Simulation Program, 2002. http://gundog.lbl.gov/. [34] TRNSYS, The Transient Energy System Simulation Tool, 2002. http://www.trnsys.com/. [35] CFX, AEA Technology Engineering Software. http://www.aeat. com/cfx/. [36] Cylon Controls. http://www.cylon-controls.com/. [37] IAI BS-8 Project. http://eetd.lbl.gov/btd/iai/bs8/. [38] V. Bazjanac, J. Forester, P. Haves, D. Sucic, P. Xu, HVAC Component Data Modelling Using Industry Foundation Classes, SSB, 2002.
1090
D.T.J. O’Sullivan et al. / Energy and Buildings 36 (2004) 1075–1090
[39] J.E. Pakanen, T. Sundquist, Automation-assisted fault detection of an air-handling unit implementing the method in a real building, Energy and Buildings 35 (2003) 193–202. [40] T.I. Salsbury, R.C. Diamond, Fault detection in HVAC systems using model-based feedforward control, Energy and Buildings 33 (2001) 403–415.
[41] ARCH, A Building Energy Reference Tool. http://poet.lbl.gov/arch. [42] Cal-Arch, California Building Energy Reference Tool. http://poet. lbl.gov/cal-arch. [43] Labs21-LBNL A-Team, Benchmarking Database Tool, Labs for the 21st Century, 2002. http://labs21.lbl.gov/bm.html.
