*Article* **BIM-Based Life Cycle Assessment of Buildings—An Investigation of Industry Practice and Needs**

**Regitze Kjær Zimmermann \*, Simone Bruhn and Harpa Birgisdóttir**

Department of the Built Environment, Aalborg University, A.C. Meyers Vænge 15, 2450 Copenhagen, Denmark; simoneb@build.aau.dk (S.B.); hbi@build.aau.dk (H.B.)

**\*** Correspondence: rkz@build.aau.dk

**Abstract:** The climate debate necessitates reducing greenhouse gas emissions from buildings. A common and standardized method of assessing this is life cycles assessment (LCA); however, time and costs are a barrier. Large efficiency potentials are associated with using data from building information models (BIM) for the LCA, but development is still at an early stage. This study investigates the industry practice and needs for BIM–LCA, and if these are met through a prototype for the Danish context, using IFC and a 3D view. Eight qualitative in-depth interviews were conducted with medium and large architect, engineering, and contractor companies, covering a large part of the Danish AEC industry. The companies used a quantity take-off approach, and a few were developing plug-in approaches. Challenges included the lack of quality in the models, thus most companies supplemented model data with other data sources. Features they found valuable for BIM–LCA included visual interface, transparency of data, automation, design evaluation, and flexibility. The 3D view of the prototype met some of the needs, however, there were mixed responses on the use of IFC, due to different workflow needs in the companies. Future BIM–LCA development should include considerations on the lack of quality in models and should support different workflows.

**Keywords:** life cycle assessment (LCA); building information modeling (BIM); environmental impact assessment; sustainability; building life cycle; integrated design process; digitalization; greenhouse gas emissions; IFC; visualization

#### **1. Introduction**

The climate crisis necessitates an intensive investigation into reducing greenhouse gas (GHG) emissions. Here, buildings have a large reduction potential, as they are responsible for 38% of the energy and process-related GHG-emissions, globally [1]. To reduce the environmental impacts, life cycle assessment (LCA) of buildings is increasingly used. LCA is a widely used and accepted method of assessing the environmental performance of buildings. Moreover, LCA will in the near future become a mandatory requirement in several European countries such as Denmark, Finland, France, and Sweden [2,3]. However, the complexity and the time-consuming work related to LCA has often been considered a barrier [4–6], which now has to be overcome. Consequently, the efficiency potentials from using building information modeling (BIM) has gained attention in the literature [4,7], where several strategies for the workflow exist [7,8]. However, BIM–LCA is still at an early stage [7] and research on the topic is limited [4]. Some areas where research is lacking concern user-friendly platforms to assist in integration [4]. Further, to enhance interoperability between tools, integration methods with open file formats such as industry foundation classes (IFC) should be considered [4], which is currently less common in literature case studies [7].

The life cycle perspective is important because it includes considerations of material impacts. Due to previous years' political focus on reducing the operational energy use of new buildings, the impacts from materials have shown increasing importance [9–14]. The LCA method is described in ISO standard 14,040 and 14,044 [15,16] and, specifically

**Citation:** Zimmermann, R.K.; Bruhn, S.; Birgisdóttir, H. BIM-Based Life Cycle Assessment of Buildings—An Investigation of Industry Practice and Needs. *Sustainability* **2021**, *13*, 5455. https://doi.org/10.3390/su13105455

Academic Editor: Antonio Garcia-Martinez

Received: 28 March 2021 Accepted: 10 May 2021 Published: 13 May 2021

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

for buildings, in the European standard EN 15,978 [17] from CEN TC350. Several nations have made their own method specifications considering the national contexts [2]. Life cycle assessment is used in sustainable certification systems [3,18,19], but several countries are considering or have decided to include limit values for GHG-emission in legislation, such as Denmark recently adopted [20]. Time and cost are part of the considerations from clients and legislators. Since some find the complexity of LCA high [21–23], this can be a barrier in the prioritization of LCA in the building industry. Especially for the early design stages, it can be an advantage to make LCAs quickly and often in order to support an iterative design process [24–26]. BIM can simplify the establishment of the life cycle inventory (LCI) for the LCA by eliminating the need to reenter information that is already available in the building model. Several studies have focused on BIM–LCA, but not through an industry perspective, where information is relevant for practical implementation in industry. The use of BIM in the industry is in continuous development. The use of BIM for public procurement is supported through EU directive 2014/24/EU [27], with national legislations [28]. In several countries, including Denmark, the use of BIM is required for public procurement of buildings, and the delivery must happen through IFC, which is an open interoperability standard [29,30] for architecture, engineering and construction (AEC), and facility management (FM). Several BIM–LCA studies have focused on IFC to support interoperability [31–34], however there is still a challenge with the poor design of the models [4,35]. This challenge could be addressed through a transparent and visual BIM–LCA approach. Here, some studies on BIM–LCA have focused on visualizing data from LCA directly in the model [36–38]. Further, some existing tools work with both IFC and visual interface such as the EveBIM in connection with Elodie [39], and the 6D-BIM-Terminal [34]. They use different approaches and focus on national contexts and specific situations, such as on the tendering stage. IFC and 3D view are also used in a Danish context, where a prototype has been developed to represent the workflow.

While prior studies have focused mostly on published academic case studies [4,7], BIM–LCA has become more common in industry practice. However, few studies on the practical use of BIM–LCA in the industry exist. The aim of this paper is to investigate this research gap by examining industry practices and needs in BIM–LCA. This includes the specific challenges related to the design of the models, and feedback on a prototype developed for the Danish context focused on the use of open neutral file formats and 3D view. "BIM" can be used to refer to more information-heavy tools and processes, but will in this study also include more simple, geometry modeling tools. Research questions in this paper are: (1) What workflow and challenges are related to BIM–LCA in industry practice? (2) What are needs for BIM–LCA in industry and are they met through the Danish prototype using open neutral file-formats and 3D view?

#### **2. Background**

#### *2.1. Data Requirements for LCA of Buildings*

While digital building models have an obvious advantage in creating the bill of quantities (BoQ), it is not the only data input required for an LCA. Following the terminology and method from European standard EN 15,978 [17], examples of additional data are operational energy and water use, service lives of products, transport, and maintenance and repair. These cover the different life cycle stages in order to determine the LCI, see Figure 1. Cavalliere et al. [40] have made an in-depth structure of relevant information to a BIM–LCA workflow. Furthermore, life cycle impact assessment (LCIA) has to be made, or an LCIA database for, e.g., building products, can be used. Different databases are available, and their use is typically connected to the choice of LCA-tool [41]. Since local adjustments in methodology for the building LCA exists [11], different data may be necessary depending on the context and goal of the LCA. These additional data can either be contained in the building model, or need to be added later on, for instance in an LCA-tool.

**Figure 1.** Examples of data requirement for LCA of buildings. Requirements and data structure can depend on the goal and context of the LCA.

#### *2.2. Approaches for Integrating BIM and LCA*

The literature distinguishes between adding environmental data into the building model, and only extracting information, such as the BoQ from the model [42,43]. Further, Wastiels et al. [8] categorize BIM–LCA integration into five approaches. These approaches also include the approach where LCA information is added to the model. This "enriched BIM" approach has the advantage that less information for the LCA needs to be manually attributed later on, thus supporting an automatic or semi-automatic workflow, which will greatly reduce human error [33]. Furthermore, centralizing data in the model can be an advantage in future uses of the model, such as facility management where an LCA may need to be redone [33]. Challenges for this approach are that the working environment for exchange of this information has to be established [33], including what information and where it should be attributed in the model, as well as how the data can be exchanged. Moreover, the work associated with changing a material in the model, in order to investigate different design solutions, may be larger than in an LCA software [8]. The most common approach in the literature is the "quantity take-off" approach [7]. Here, the BoQ is exported from the building model and then connected to an LCA software. The processes within the quantity take-off approach can range between manual and automated, depending on the use of different software for automation of the process. However, the manual process is the most common approach [7]. The nature of the approach is simple, but an iterative design process can be difficult, due to the manual processes involved. Further, the workload from manual processes can be extensive. The third approach from Wastiels et al. [8] is the "import of geometry into the LCA software", for example by using IFC for data exchange. An advantage of this approach is that IDs for the objects are used in the data exchange. This makes it easier to update the LCA without matching geometry and environmental data all over again. The fourth approach applies an intermediate "viewer" in a 3D environment, where information from, e.g., the IFC, is matched with environmental data. This approach has the same advantage with the use of IDs as the previous approach. Further, the match can happen within a 3D environment. For the previously mentioned approaches, there was no visual connection to the 3D environment of the building for the processes of matching data or visualizing results. The last approach also uses the 3D environment. This is the "LCA plugin" for the BIM software. Here, the BIM software automatically provides the 3D environment for matching and visualizing results dynamically for an iterative design process. The five approaches can be seen in Figure 2.

#### *2.3. Data Exchange in BIM–LCA*

The above-mentioned approaches are distinguished by their overall workflow; however, a crucial dimension is the type of data exchange. The data exchange within the tools available to the practitioners can limit their options for workflow.

Interoperability is typically the goal within data management between software solutions, to allow for easy exchange of data between software. Laakso and Kiviniemi [30] distinguish between the direct interoperability and open interoperability standards. An example of the open interoperability standard is IFC. The IFC schema is a standard, open, and vendor-neutral data model, describing the built environment [44]. Using a standard

structure requires all relevant software to translate their data into the standard structure, thus creating a common language for all software to exchange data. For BIM–LCA, it is important to consider if the standard structure can contain the data you want to extract from your model, as described in Section 2.1. Using a standard data structure will always restrict how data can be described, and thus used in the building performance tools [45]. However, data interoperability using an open standard data structure has obvious advantages as it reduces the number of times data need to be translated [30], see Figure 3. In principle, the standard data structure can be used in all five approaches mentioned in Section 2.2, except the plugin solution.

**Figure 2.** Five approaches to integration of BIM–LCA, as defined by Wastiels et al. [8].

**Figure 3.** Data exchange from digital building model to LCA-tool using open interoperability standard and direct interoperability.

Alternatively, data can be transferred via direct interoperability, which requires some openness from the software providers in data structure [30]. This can be a challenge when proprietary data schemas are used. However, with an open data structure, data can be exchanged using, for instance, a file format to the target schema needed in the LCA. Open file formats that have been used for LCA are, for instance, xlsx [7]. These formats are typically used in approach 2 (quantity take-off), but can in theory be used for all above defined approaches, depending on the chosen data structure. The difference between this and the open standard data transfer is that it is not standardized, thus all transfers between tools, in principle, need to be made individually from each building model software to the LCA-tool, instead of using a common structure, see Figure 3.

Furthermore, software can provide the possibility of using plugins via an application programming interface (API) to exchange information with the software. An advantage of plugins is that it can add functionality to the original software, for instance, by visualizing results and receiving dynamic feedback on design changes within the building model environment. The plugin middleware can also select the specific data needed from the model for the data exchange with the LCA tool. Popular plugin solutions in the building sector are visual programming languages (VPL) [46], such as Grasshopper [47] and Dynamo [48], which make programming more available to architects and engineers. Plugin solutions can work alone without external dependencies, or as a bridge to an external LCA-tool. Approach 5 from Section 2.3 is defined as the plugin solution, however, a plugin can also work in connection with intermediate data schemas or formats. For example, VPL can be used to extract quantities and create an xlsx file, which can then be transformed to the LCA-tool data schema.

Some disadvantages of direct transfer are handling of software versions and errors in translation [30]. Furthermore, the plugin will only work with the specific software for which it is developed.

#### *2.4. BIM–LCA at Different Design Stages*

Data exchange in BIM–LCA can happen at different design stages where information in the models varies. Even within the same model, the level of development (LOD) can vary [49]. In early stages, the data for LCA from the building model is limited, and may not contain information on materials, for example. Conducting BIM–LCA at different LOD has previously been addressed in the literature [37,49–52]. Cavalliere et al. [49] and Röck et al. [37] suggest the use of predefined components based on the LCIA database for building materials when specific quantities are not known. For even earlier stages, average data for components or elements is suggested [49]. Predefined elements and components have also been suggested for early design LCA in general [2,21,24].

#### *2.5. Prototype with Workflow for BIM–LCA*

#### 2.5.1. Context

A prototype has been developed in a Danish context as a possible workflow for BIM–LCA. The prototype only has some key features implemented, as well as some of the interface in order to give an idea of the functionalities. For the Danish Voluntary Sustainability Class [53] and the Danish adaption of DGNB (Deutsche Gesellschaft fur Nachhaltiges Bauen) [54], it is mandatory to use the environmental product declaration (EPD) or use the LCIA database, Ökobaudat [55]. Thus, one of the main goals for the BIM–LCA integration process is to gain information on material quantities and match the information with environmental data. The information is connected to the Danish national tool, LCAbyg [2,56].

#### 2.5.2. Workflow

A prototype for BIM–LCA was developed to meet some of the challenges associated with poor design of models. The prototype was developed using the "viewer" approach as described in Section 2.2., but also closely related to the "import of geometry" approach,

because the prototype is closely connected to the dedicated LCA software. The general idea of the developed prototype is: (1) the use of standard and open file-based exchange with flexibility in data input to support use across different design stages; (2) create a visual interface in order to enhance the quality and documentation of BIM-based LCA, and to support an iterative design process. The workflow is shown in Figure 4. From the building-model software, the data is exported to an open file format. This format is imported into the prototype, where the necessary information is added in order to perform the LCA, including matching the BoQ with LCIA data. The matching of BoQ with LCIA data happens manually or semi-automatically in the 3D environment based on the information available from the model, and the library of LCIA data. The semi-automatic process consists of suggestions of matches based on previous matches or material names. Further, objects with identical material composition can be grouped together and matched to LCIA data using names, classification, IFC-structure, shape, etc. This process can be further automated if information from the LCIA library elements have been implemented in the building model, following the approach of "enriched BIM". In the 3D view, the object placement and quantities can be visualized. The LCA is carried out in the Danish LCAbyg-tool. LCAbyg is connected to the prototype through direct interoperability in python, using JSON-format to exchange information with LCAbyg. The prototype can be used to visualize results from the LCA directly in the 3D-model.

**Figure 4.** Workflow for BIM–LCA in the prototype. At different design stages, it is possible to work with different types of available information from the model.

#### 2.5.3. Use across Different Design Stages

Due to variations in LOD of models during a building project, the prototype uses predefined components as described in Section 2.4. The user can match predefined components with the quantities in the model. All quantities are calculated and available in the prototype tool, thus it is possible to use the quantities that are relevant at the current design stage of the building model. In earlier stages with low LOD, the material information is likely not modelled. Here, environmental data for predefined components or elements can be matched with areas extracted from the building model. Predefined components are a part of the library in the Danish LCAbyg tool [57,58]. At later stages, the specific material quantities can be extracted from the digital model, or added within the prototype. This is illustrated in Figure 4. Results are provided through the LCAbyg tool.

#### 2.5.4. Open File-Based Data Exchange

Open, file-based exchange was chosen as the data exchange in order to support a wide range of software for the digital models without creating middleware for each individual building model software.

For the prototype, two file formats have been selected for the data exchange: the IFC schema for the more complete data exchange, or OBJ for a limited data exchange. IFC is an open standard data model for AEC and FM, and can be represented through a file-based exchange [30]. OBJ is an open file format for describing 3D geometry. OBJ is strictly geometry, whereas IFC contains object based information which can store a large variety of data on the building. The information available in the IFC depends on the Model View Definition (MVD) [44] and can be different depending on the used building model tool, or the selections the user makes when they export their model to IFC. A specific MVD can be made for the data exchange, and has been developed in other studies [32,33,59]. However, for now the prototype will not require any specific information in the IFC. This way, the tool will be able to support all IFC models, no matter how they have been processed previously by software and users. The OBJ can act as a practical alternative to IFC because the process of import and export is faster than IFC, and the limited data exchange of OBJ will likely be enough for the early design stages where geometry is the only information available in the building model. Furthermore, export to IFC is not always accessible in the design tools (see Table 1). IFC and OBJ both use unique IDs for objects, making it possible to have an iterative process in the building design, without repeating the manual processes, as described in Section 2.2.

**Table 1.** Export options for Industry foundation classes (IFC) and geometry file format OBJ from different model software.


<sup>1</sup> Not available in the free version. <sup>2</sup> Requires purchasing of plugin.

#### 2.5.5. Visual Interface

The visual interface in the prototype was achieved through an interactive 3D view of the building. See Figure 5. In this view, it is possible to navigate similarly to other 3D tools (zoom, rotate, etc.). When the user targets an object, the available information for the LCA is shown, such as quantities and material information. IFC and OBJ can both provide 3D-object information, necessary to visualize the building. The visual interface is where the BoQ is matched with LCIA data. Further, the 3D interface can be used to visualize results from the LCA. It is also meant to give a better understanding of the origin of the BoQ, and if there are collisions, missing or wrongly categorized objects, or other errors. The modelling errors become easier to find when they are visualized in the 3D model. The prototype calculates the quantities, but the user can also choose to use quantities from the original building-model software if they are included in the IFC. Moreover, it is always possible to overwrite the quantities or other information from the model.

**Figure 5.** Prototype interface with 3D view of the building.

#### **3. Materials and Methods**

#### *Qualitative Interviews*

Data in this paper is based on qualitative in-depth interviews with companies who perform LCA of buildings. The goal of this method is to understand the company perspective on performing LCA of buildings, such as their current practices and motivation behind them, as well as demands for better workflow and feedback on the presented prototype.

The qualitative interviews consist of eight semi-structured interviews with companies in the Danish building sector, who offer LCA of buildings as a service. The companies were selected to represent a variation of company types with consultant services, from architect, engineering, and contractor firms. For further details, see Table 2. Contact with the companies had already been established through previous projects with LCA in the building industry. Prior to the interview, the themes of the interview were given to a contact person in the company and they were prompted to bring relevant informants from the company to the interview. Further, the questions were sent to the companies prior to the interviews, to give them an opportunity to prepare, or ask others in the company if they didn't have the answers themselves. The semi-structured interview focused on the following questions. Prior to the last question on the list, a presentation of the developed prototype was given:




The interviews were analyzed and categorized using a combination of deductive and inductive coding technique [60]. The deductive coding technique is based on the theoretical background, and the inductive coding technique arose from informants discourse. The purpose of this is to understand the companies' workflow in relation to the existing literature on, e.g., the BIM–LCA approaches presented in Section 2.2, while including themes that arose from discussions with informants, such as the challenges they meet in BIM–LCA.

The eight interviews were comprised of 15 informants and were carried out in November and December 2020, and January 2021. The informants were engineers, architects, and

design engineers. They covered informants with knowledge on LCA of buildings and, for some companies, informants that work across disciplines with a focus on sharing and using digital building information.

As stated above, the companies represent a broad variety of professional profiles and companies. The companies cover large and medium size companies, but not small or one-man businesses. Due to the size of the interviewed companies, they cover a large part of the Danish AEC industry, but it should be noted that the building industry in Denmark also consists of many smaller companies [61,62]. For this research, smaller companies were considered to have too little experience in BIM–LCA to give valuable input. The interviewed companies were chosen due to their knowledge and practical experience in performing LCA on buildings. The selected companies are part of an LCA expert group, who are consulted in relation to the development of the national tool for LCA on buildings, LCAbyg [2,56]. Due to their advanced knowledge in comparison to many other, and smaller, companies, their experience can inform in more detail on practical workflow and challenges as well as demands.

#### **4. Results**

#### *4.1. BIM–LCA Workflow in Companies*

The most commonly used BIM–LCA workflow in the companies is the quantity take-off approach, as presented in Section 2.2, and a few of the companies have started development on the LCA-plugin approach for the BIM software. However, the companies work differently within the approaches. Figure 6 illustrates how the individual companies work within the two approaches. All companies use direct interoperability for data transfer, but with some differences in approaches. Three of the companies use export of schemas from the BIM software, Revit, to Excel, in order to create the BoQs from the BIM. At times, company H creates the BoQs using a Dynamo script from Revit to an xlsx-file, along with company C and D. Here, company B uses a C# script for the same process of creating an xlsx file. All the mentioned companies manually transport the BoQs in the xlsx file into the LCA software, LCAbyg, where the LCA is done. However, company D typically uses their own excel tool for the LCA, and only does the final calculation in LCAbyg.

Company E uses a semi-automatic BIM–LCA workflow, where the BoQs are created from a Rhinoceros-model (Rhino) using a Grasshopper script. A library with predefined constructions can be linked by the user to the BoQs in Grasshopper, and JSON (JavaScript Object Notation) files are created according to the target schema in the LCA software, LCAbyg. Company A also uses a semi-automatic BIM–LCA workflow, where the BoQ in excel is created from a Revit model using Dynamo or export to Excel. In the Excel file, they can match BoQ with IDs for LCIA data. Based on the xlsx-file, a script transforms the data to xml files according to the target schema in the LCA software, LCAbyg.

Currently, some of the companies are developing the LCA-plugin approach for the models, to use in the early design stage. Company C is working on a solution for early design stage, using Rhino and Grasshopper, and company D is working on a tool using Revit, Power-BI, and matching via classification codes. These are still under development, and have not been included in Figure 6. Company G has recently developed a plug-in solution for the BIM software, Revit, where LCA results can be shown dynamically as the user edits the Revit model. The environmental impacts from a library with predefined constructions are linked to the keynotes in the Revit model.

#### *4.2. Data Used for BIM–LCA*

A BIM model is naturally used in the BIM–LCA workflow; however, several other data inputs are used within the companies. Figure 7 illustrates the different sources of data used for building models and how, in most cases, this information is supplemented with additional data.
