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

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.

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,5,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,10,11,12,13,14]. The LCA method is described in ISO standard 14,040 and 14,044 [15,16] and, specifically 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,22,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,25,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,32,33,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,37,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.

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.

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,50,51,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.

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. Export options for Industry foundation classes (IFC) and geometry file format OBJ from different model software.

Model Software	IFC	OBJ
Revit	x	x
Rhinoceros	x 2	x
Sketchup	x 1	x 1
ArchiCAD	x	x
AutoCAD	-	x 2
Vectorworks	x	x

¹ Not available in the free version. ² Requires purchasing of plugin.

). 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.

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.

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. Overview of the company type and informant profiles in the eight semi-structured interviews.

Interview	No. of Informants in Interview	Profiles	Company Type	No. of Employees in Denmark (in Ranges)
A	2	Engineers	Consulting engineers and architects	3000–3999
B	2	Engineer and design engineer	Consulting engineers and architects	1000–1999
C	3	Engineer and design engineer	Consulting engineers	100–199
D	1	Engineer	Consulting engineers	500–999
E	2	Engineer and architect	Consulting architects	100–199
F	1	Architect	Consulting architects	0–99
G	2	Engineer and architect	Consulting engineers and architects	3000–3999
H	2	Engineers	Contractor and consulting engineers	1000–1999

. 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:

• Which digital building model tools (“BIM”) and LCA-tools do you use today?
• How is the BIM–LCA workflow in the company today, and why?
• How do you work with BIM in relation to LCA? E.g., use of discipline models;
• What challenges do you face in BIM–LCA?
• What is most important for a good BIM–LCA workflow? E.g., quick, automation, ease of use, transparency/quality assurance, flexible workflow, precision of data, visual/3D view, evaluation of design solutions, understand LCA and material impacts.
• Does the prototype satisfy these important aspects? What does it meet/doesn’t meet, and why?

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.

Different models exist during a project, and this is reflected in their use within the companies. In general, all the companies mention Rhino as a tool that is used in early design stages, where Sketchup and AutoCAD is also mentioned in a couple of the companies. The Rhino models are in some cases used for the LCA as illustrated in Figure 6. In the more detailed stages, all companies use Revit. They describe Revit as almost an industry standard when modelling in the project design stage. The companies work with different discipline-oriented models in Revit: an architectural model, structural model, and mechanical, electrical, and plumbing (MEP) models. All companies use the architect model for the LCA, but only two companies mention that they extract the data from the structural model and the MEP models to perform the LCA, and only in the detailed design stage.

To supplement data, and to fill the data-gap from only using the architectural model, the companies mentioned additional data sources. These include descriptions of building elements, data from sub-contractors, and gathering data from the discipline groups such as the structural or HVAC (heating, ventilation, and air conditioning) engineer. Two companies also mentioned the use of experience-based values from earlier projects or the literature to supplement in earlier stages, when data is not available. The use of descriptions of building elements is mentioned by company B, C, and H for LCA in the early design stage, when information in the model is limited or when it is not defined in the BIM. Element details are gathered from the supplier, for example the concrete element supplier, because they have more detailed information on the elements. If information or data are missing in the BIM model, the companies contact the discipline groups to collect the missing information. An example of this is company A, who collects information by providing the different discipline groups with Excel sheets, where they can fill in the data.

4.3. Challenges in BIM–LCA

During the interviews, the individual companies were asked which challenges the company faces when making LCA from the building models. The challenges are listed in

Table 3. Challenges of BIM–LCA mentioned by the companies.

Challenges	Comments
Lack of building-model management for a collaborative process	Those who need information from the model (e.g., quantities of materials) are not the ones who model it (A, F, C); Modelling starts very late in some projects, especially the structural model (G); The consulting engineer may not design the ventilation system themself, but puts it out to tender. Thus, they don’t have the model (G, F); Contractual issues means that they cannot edit in, e.g., the architectural model (D); No minimum demands for LOD on material information exists (A); No common understanding or standard for extraction of quantities (F); Challenging to motivate other actors to include materials in the Revit model, when it takes long, and gives no value to the one who does the modelling (F); Lack of responsibility of the quantities in models (A);
Workflow errors	Human error when manually typing into LCAtool from 8–10 different Revit schedules (F); Extracting quantities from Revit is a black box, where it is not possible to see if anything is missing (F); Difficult to check the models for errors, when someone else has made the model (A); Paint areas are wrong, if the suspended ceiling is not accounted for (A);
Lack of data availability and quality in models	The data in the models are not good enough to form a basis for a good BIM–LCA integration (A); Issues with extracting correct quantities from the models (F), specifically volumes (D); The models are modeled incorrectly in terms of extracting quantities, although the graphical representation of the model looks correct (F); Quantities will always be incorrect to some degree (C); 10–15% of the model is not modelled correctly (G); Quality of the modelled elements vary (G); MEP model is not used for the LCA because it is not good enough. They collect the quantities on a list from the engineer (G); Structural model from the consulting engineer is not as good as getting information from element supplier (G); Not all materials are modeled in the model, e.g., steel in the plaster wall (B); Detailing is not very high in the Revit model, e.g., they don’t model reinforcement or holes in slaps (G); Detailing varies (C); Not all data are available in the model and likely never will be (C); Often there is no structural or MEP building model (more often in office buildings, as they have higher demands) (G); Information is not in the Revit model, only geometry (E); Materials are not in the models (D, A);
Modeling errors	Delta beams, piping, etc. are drawn as solids, resulting in the wrong volume (A); No reinforcement in concrete elements (A); Errors in model, e.g., internal walls are modelled as external walls (H, C) or as wall instead of foundation (A); Some elements are modelled doubled, because several disciplines have modelled them (e.g., architectural and structural models both include structural elements). There is a risk of double counting (A, F, G); Wrong dimensions of elements (A); Columns drawn through slaps, giving the wrong volume (A); Windows drawn as curtain walls (A);
Variations in the structure of models	The structure in the models varies (B, D), and the model they get from the architect is structured differently each time (C); The structure of the objects in the models varies (B), e.g., variation in the construction of the floor; with or without deck, etc. In the early design stage the objects are modelled as generic elements, while in the detailed design stage the building elements are modelled with all functional layers, e.g., ceiling, floor; Modelling is different in other nations (G);
Data exchange and matching model-data with LCIA data	Quantity outputs units from models are sometimes difficult to use for LCA, e.g., ”pieces” of stairs (G); Matching quantities with LCIA data from LCAbyg (C); It is a challenge to create generic plugin scripts for all models as they are modeled differently. They always need to adjust the VPL/script (D); Difficult to predict the future and thereby develop tools or a workflow for future processes (A); Oversimplified or too user-friendly tools (F); Issues with stability and/or workflow of different VPL (A, B, C, F, H);
Manual workflow and large models	Time consuming with manual BIM–LCA workflow (F, G); Extracting quantities/checking data is the most time-consuming process (D, A); The large number of elements in a model makes it a time-consuming process (A); Too much information in the models can make them slow to work with (D).

, where they are separated into eight overall challenges.

Some of the most commonly mentioned challenges are the lack of data availability and quality in the models used to establish the BoQ. An architect mentions that the models have not been made for the purpose of quantity extraction, but with other aspects in mind, thus the quantity take-off is wrong. It is also mentioned that some of the discipline models, such as structural and MEP, often do not exist, or are not reliable for quantity take-off. Further, the detailing varies, but some materials are simply not included in the model, such as reinforcement, and steel in plaster walls. Several mentioned that it is not likely that quantities will ever be completely correct in the model. Model errors are listed as a separate challenge in Table 3, however, they only contribute to the lack of quality in the models.

Furthermore, the structure and classification of the models can vary a lot, which can influence the data exchange. For instance, if a plugin expects a certain structure, but the model doesn’t have this structure. When matching the BoQ to LCIA data, a common challenge mentioned is matching the units, as they may not align. It is also a source of human error, if the match is done manually. Some mention that the manual processes are time-consuming. This also includes manually checking the quantity take-off, due to the above-mentioned lack of quality.

To some degree, these challenges are a result of the lack of management or standardization of the models in relation to LCA, where some mention the lack of method for extraction of quantities, requirements for input of material information, and good-quality models at the time that they need them for the LCA. Further, those who make the LCA are often not the ones who make the building models. Therefore there is a lack of incentive for modeling for quantity take-off, or a lack of responsibility of the quantities in the model which is needed in this collaborative modelling work.

4.4. User-Perspective on Integration and Response to Prototype

The informants were asked about features for the integration process that they found important, and afterward they were presented with the prototype from Section 2.5 and provided feedback. Both of these results are shown in

Table 4. Important aspects of the BIM–LCA integration process mentioned by the companies, and their comments on the prototype.

Important Properties for Integration Process		Comments on Prototype
Ease of use (G, H)	Everyone should be able to use it. It should be simple (G); Help solve the issues in data from BIM (H);	Cons: In a building model, they have 300 different Revit “families”. This might be too much work/too complex to work with in the prototype. (A, B, F); Worried that the tool cannot handle larger models (that the program might crash) (D, G);
Visual interface (A, B, C, D, E, H)	Important for early design stages (D, E); Interface with 3D-model (A, E, H,); To communicate and discuss results of LCA with other actors (B, C);	Pros 3D interface (C, D, E, F, H); Communicate result to client (B); That you see a 3D view of the actual building, you are working on, not just a generic model. (F); You can see the objects you have matched to LCIA data vs. those you haven’t yet (F); Cons: It might be faster to manage the data without the 3D view. They don’t always need a 3D view, if it takes more time (B, C);
Evaluation of design solutions (B, C, G, E, H)	Show where to focus the optimization, e.g., the largest impacts (H); Comparison of building elements and materials (B); Comparison with their own or certification references/benchmarks for buildings (B, H); Important for early design stages (E);	Pros: Comparison of design solutions (B);
Transparency of data from the building model (A, B, C, H, F)	They need to assess the quality of the model, therefore, they need to see how BoQ is connected to the information from the building model (H); The models will likely always be wrong, so they have to check it (A, B); Possible to see where there are changes or new objects, when you update the model (C); Highlight obvious errors, e.g., the building being much heavier than similar building. (F); 3D visualization with names and thickness of elements (H);	Pros: Quality assurance of data, especially when elements can be filtered/grouped together (G); See all the building elements in 3D view (H); Easy to understand the origin of quantities with 3D view (D, A); You can see how areas are calculated due to the 3D view (C); Quantities are also calculated within the tool, not just quantities from Revit (F); You can more easily see if you are missing element/materials (F); Collision control (F); Cons: Too complex in larger models to do quality control (B);
Precision and completeness of BoQ data (B, D, E, F)	The LCA should have large detailing already at early stages. Therefore you should be informed of missing elements, e.g., ventilations systems (F); Quantities from the building model should be correct (D); Important at later stages (D, E);
Quick/automation (B, C, D, H, F)	Currently, there are too many steps before the final LCA can be made (H); They spend many hours extracting quantities (B); Retrieve quantities from the model and update them automatically when the model changes (B); The matching of BoQ with LCIA should be remembered when the model is updated (B); If 80–90% of the process in the future will be automated, it will be a great help (B); To make an automatic match of quantities with LCIA data, LCIA should be included in Revit/IFC (B); Automation of the processes is a good idea, because human errors are difficult to find (F); Important for early design stages (D);	Pros: Easy to update the model, due to ID’s when using IFC (F); The prototype tool contains the library used in the Danish tool, LCAbyg (H); Cons: Not dynamic or parametric (E); If the architect deletes a wall and draws a new wall, it will have a new ID, and then you cannot as easily update the LCA anymore (C);
Flexible workflow in terms of data sources (A, C, E, F, H)	Import of IFC and Revit, as this is what is most commonly used in the industry (H); Not certain that Revit is what we use in the future, therefore more file formats should be possible to use (F);	Pros: Can possibly solve the issue with the uses of different building model tools in the industry (H) Neutral file format (H); The possibility to use areas as quantities and match with LCIA-data for predefined elements, as an alternative to specific quantities such as m3, kg. (D); Choose what data, they use from the models, because they know that some information is not correct (A); Possibility to overwrite and adjust quantities and structure from the building model in the LCA (G); Cons: They prefer that it is made specifically for Revit, because they mainly use Revit (D); They might prefer exchange via files such as 3DM or MWD as it might be faster than IFC (C);

. In terms of important features for the BIM–LCA, one of the informants said that the integration should help solve the data issues from BIM. This refers back to the challenges, mentioned in Section 4.3, where several companies questioned the quality of their models, and their completeness. The 3D view was mentioned as a positive feature in connection to transparency of data from the model. Due to the quality of the models, they need to check the quantities, thus the 3D view will help them understand the origin and calculation of quantities, and to see if there are collisions of elements. The 3D view was also mentioned in relation to visualization, where several companies suggested it and found it to be a positive feature in the prototype. In general, six out of the eight companies mentioned the positive in a visual interface for the BIM–LCA integration. They mention its positive effects on communication and discussing results with different actors of the projects, especially at early design stages. Two engineering companies stated that they do not necessarily need a 3D view, as they were worried that the integration process would take longer. In terms of ease-of-use, some worried that the general workflow in larger models might be complex, if they need to review and match all this data with LCIA-data. However, some said that the grouping and filtering of elements can be used to manage the data.

Automation was another theme several of the companies found important. One of the informants mentioned that the models will likely always be wrong, but they still see potential in automating 80–90% of the process. Another informant mentions that automation is valuable, because humans make mistakes, and human mistakes are much harder to find. Automation also has relevance in terms of efficiency, where they currently spend many hours extracting quantities and go through several steps to make the LCA. To make automation easier, one informant suggests to “enrich” the BIM with information that can automatically match to the LCIA data. When presented with the prototype, one found it positive that the IDs from the IFC would make it easy to update the model, while another mentioned the lack of dynamic or parametric features.

Five companies also find the flexibility of data sources important. One mentions that IFC and Revit are the most commonly used data sources in the industry, and thus should be supported in a tool for BIM–LCA. Another mentioned that it is not certain that Revit will be the main tool in the future, therefore other data sources should be supported. When presented with the prototype, some found the use of a neutral file format positive, while others preferred to focus on Revit or use different file formats than IFC and OBJ. Some had a general experience of “loosing” their data when they had previously used IFC in their work. In the prototype, some found the flexibility positive; in terms of choosing only the data that they find relevant from the model, as well as the type of quantities relevant to the stage of the project, e.g., choosing areas instead of kg and m3 for early design.

Evaluation of design solutions was also important to consider in BIM–LCA for several of the companies, in order to get instant feedback on design solutions and whether or not they meet certain benchmarks. Four of the companies also mentioned that precision of data is important, including completeness of data already in the early stages, such as by including installations. Referring back to the challenges in Section 4.3, this information may not be available in the model and thus have to be added in the BIM–LCA process.

5. Discussion

5.1. Data Management

The companies interviewed for this study only used the model to store data related to extracting the BoQ. However, storing more LCA-related data in the model can reduce human error, support automation, and facilitate better use of the models across the life cycle of the building [33]. Moreover, it complies with the concepts surrounding BIM, which focus on information sharing and collaboration across the building life cycle. However, the workflow for this “enriched BIM” first needs to be established [33] and may vary depending on the goal and context of the LCA, as well as the structure used in the model. Further, if the model includes environmental data, it can be a challenge to manage if it is up-to-date [63]. Inclusion of environmental information in the BIM and using the IFC-viewer workflow has been tested in the literature before, with more focus on the later stages [59]. However, the process is associated with practical challenges, because even though IFC can contain this information, some properties, attributes, and entities are not available in industry BIM [59,64]. Further, the IFC schema still needs to be improved to allow information for a full LCA [33].

Despite only using BoQ data from the model, the companies are met with challenges related to the quality of the model and many use supplementary sources to complete or detail the BoQ. Poor design of models for LCA and life cycle performance has been recognized in the previous literature [4,35], and is confirmed and specified in this study. While future legislation demands for LCA might improve the collaboration related to quantities in the models, several companies expressed that it is not realistic that the models become perfect in terms of quantity extraction. An issue therefore lies both in how the BoQ data from the models can be improved, and what expectations regarding the precision of BoQ is expected from the building LCA at different stages. Automation could be a possible solution to improve upon the data quality, such as automatically adding reinforcement in concrete elements. However, automatic or semi-automatic approaches can also be imprecise and reduce transparency in the process. In terms of the expected precision of the LCA, the practitioners will likely need clear guidance regarding this aspect in relation to benchmarking their building.

In early design stages other strategies can be used, such as matching quantities with predefined elements, as suggested in this article as well as in previous studies [2,21,24,37,49].

5.2. Tool for BIM–LCA

The prototype for the Danish context includes the visual interface in correlation with conducting the building LCA. The companies were generally positive towards the 3D view in the prototype for both transparency of data and visualization of results. Some of the companies were also working towards their own plugin approach with 3D view, especially for early design stages. In the development of the prototype, it could be relevant to be inspired by the plugin–workflow, for instance by allowing the user to modify the geometry in the prototype to achieve the same dynamic effects, and test different designs. A challenge in the plugin–solution is the dependency on one specific building model tool. The companies from this study mainly use Revit, and some therefore preferred a direct data-exchange for this software. However, for the early design stages, it is more common to use a variety of tools, and some companies also expressed the positive in using neutral file formats in order to support a variety of modelling tools. It is likely that some companies will want to optimize internal processes, and thus develop their own tools, while others will require ready-to-use software. Software providers and policy-makers should therefore allow for different workflows, and provide a clear description of method.

5.3. Limitations

While the interviews can give detailed insight into workflow, challenges, and demands for BIM–LCA in industry practice, it should be noted that this study is a qualitative study with a limited sample size. Thus the results from the study represent the experience in eight different companies in Denmark. The companies cover a large share of the Danish AEC industry due to the large size of some of the included companies. The companies are of varying size, however, small and one-man businesses are not represented in the interviews, because it was assumed that they would have limited experience in the subject. Omitting the small companies can potentially have an influence on the informant’s feedback on the prototype. This is because small companies can be more dependent on ready-to-use tools, such as the prototype, because they have less resources to develop their own integration of BIM–LCA. The prototype facilitates an integration process where all models, independent from which software the model is created in and how it is structured, can be used for BIM–LCA. Future development of the prototype should therefore include considerations of smaller companies.

6. Conclusions

This paper has provided insight into industry practice of BIM–LCA through eight in-depth interviews with consulting and contracting firms. All the companies use a quantity take-off approach for the BIM–LCA and some have recently made, or are currently developing, plug-in solutions. Nevertheless, due to the lack of quality in the models, it is often necessary to supplement the model-data with data from other sources, such as element descriptions and contacting engineering disciplines and subcontractors. The lack of quality and variations in modeling are dominant challenges mentioned by the companies. Many of these issues points back to a management of the models, which is not optimal for quantity take-off. In the future, the quality of the models may improve due to legislations in, e.g., LCA, however, some degree of inaccuracy should always be expected, especially in early design stages. For the integration of BIM–LCA it should therefore be considered how the inaccuracy is dealt with. Moreover, to which degree automation can be incorporated in the process. For legislation and benchmarking, the level of detail expected for the LCA should be clearly defined.

The informants also provided needs for BIM–LCA and evaluated a prototype for BIM–LCA in a Danish context with the use of open neutral file formats and a 3D view. The companies considered several aspects important in BIM–LCA, including visual interface, transparency of data, automation, flexibility of data sources, and easy access to evaluation of design solutions. Many considered the 3D view in the prototype valuable for transparency and communication, but some questioned its efficiency and use for their larger models. The prototype uses open and neutral file formats such as IFC and OBJ for the data exchange, which garnered mixed responses from the companies. Some valued the flexibility it can provide in terms of using models from different software, while others preferred optimizing the direct data exchange to their predominantly used tool, Revit. Companies will have different resources and goals, and thus different needs in relation to workflow for BIM–LCA. Specifically smaller companies will likely benefit from ready-to-use solutions such as the prototype, because there are no requirements to the structure of the model, or the software used for modeling. A strategy for software developers and decision-makers can therefore be to allow for different workflows, but provide transparency of results and clear descriptions of method.