Solutions on Establishing and Utilizing BIM for General Contractors in Key Scenarios of Digital Construction

Abstract

Nowadays, digital construction has become popular when bringing convenience and efficiency to the traditional building construction industry. The primary tool of digital construction is the building information model (BIM). However, from the perspective of general contractors, unresolved puzzles still hinder obtaining the benefits of digital construction. When establishing a unified BIM from submodels provided by subcontractors, there will possibly be incomplete or inconsistent data during model merging. But extracting submodels from unified BIM often includes redundant data, thus making models less usable for subcontractors. It is also difficult for general contractors to effectively and accurately utilize resource information and submodel changes. This paper proposed solutions that depend on the widely adopted industry foundation classes standard to ensure the universality of our methods. First, a model merging algorithm is proposed to support the continuous merge of submodels created by different subcontractors. Second, an instance-level model extraction method based on strongly related entities is proposed, which extracts model instances to the minimum submodel and meets the subcontractor requirements at the same time. Third, the new model storage and indexing method are designed to reduce the complexity of model data and support rapid data retrieval, and a new BIM change detection method based on object metadata is provided. The proposed methods were applied by the general contractor of a large airport project during the construction stage. The application results proved that the proposed methods could ensure the quality of established deepening design models and extracted submodels and significantly reduce human labor by improving efficiency when utilizing BIM, which in turn supported key scenarios throughout the digital construction workflow.

1. Introduction

Digital construction is characterized by the use of data and information technologies, which improves efficiency and reduce cost for the application scenarios in the whole lifecycle of buildings [1], including design, construction, maintenance, and demolition phases [2]. The main work of digital construction is currently based on the building information model (BIM). The core purpose is to build a digital virtual building containing complete information about the construction process and provide the desired information for each application scenario [3]. Currently, BIM-based methods have been fully developed, but academic researchers still focus on some key scenarios in digital construction.

The three essential benefits of BIM-based digital construction are accuracy, consistency, and integrity. However, they have also featured the main difficulties in the establishment and application of BIM in the building lifecycle [4]. A general contractor is responsible for managing a unified BIM and providing usable model information to subcontractors. Therefore, ensuring accurate, consistent, and complete construction information in the whole process, from the establishment to the use of BIM, is the core issue that directly decides the success of the practice of digital construction scenario.

From the perspective of the digital department of general contractor companies, this paper studies the difficulties of establishing and utilizing BIM in key scenarios during the digital construction process. To ensure the generality of the method, BIMs in this paper are defined under the framework of industry foundation classes (IFC) because it is now the only de facto standard for BIM data exchange. Therefore, the following sections will define three key digital construction scenarios and analyze existing problems that general contractors will face.

1.1. Merging Design Models from Subcontractors and Departments

The most crucial digital work for general contractors is establishing a unified BIM and maintaining its integrity from the design phase to final delivery. From the architectural design phase, subcontractors and departments create different BIM submodels of the building. For the multidisciplinary coordination of digital construction and subsequent construction organization, merging these submodels into one final BIM model is necessary. For example, the designer’s architectural and structural design models are merged into a full component model for subsequent electromechanical professional design. When merging submodels, it is necessary to ensure the integrity and avoid repetition of information as well, including (1) maintaining consistent modification information of components and (2) correctly reconstructing the association relationship, both essential.

Problem: During merging operations of designing models, the “relationship entities” in the To-merge model are likely to have the problem of missing secondary entity sets and cannot be directly added. Otherwise, the final information will be incomplete. Therefore, to ensure the consistency of the model, the algorithm must carefully analyze the changes of instances in the model extraction, modification, and merging process. Currently, some merge methods do not consider these problems, resulting in difficulties in applying them in practice.

1.2. Extraction of Usable Submodels

After establishing the unified BIM, the general contractors are responsible for providing submodels for various on-site management use. For example, the model of the first floor in this month’s schedule is extracted for progress analysis. Often the model of all steel materials is extracted and delivered to the steel structure subcontractor. Submodel extraction has two levels: entity-level and instance-level. Instance-level extraction includes filtering conditions for a particular component instance, which require attributes of instances to meet the filter condition. For example, an entity-level extraction requires “material-steel” and “type-beam” so that only steel beams are extracted while concrete beams are eliminated. In the digital construction scenario, the requirement for instance-level model extraction is considerably large [5].

Problem: Difficulties arise during the processing of related model entities. The extracted model becomes very large and useless if too many associated objects are extracted directly. For example, the progress department requires a workflow submodel containing “structural construction.” If the subtasks, pretasks, and posttasks associated with the “structural construction” task are all extracted, redundant task nodes will also be included. It is difficult to specify the extraction rules of relational entities in the submodel to ensure the extracted submodel meets the requirements and retains minimum at the same time.

1.3. Fast and Accurate Information Acquisition from BIM

Establishing proper BIM is not the end of digital construction. Instead, acquiring information from BIM is the final goal. A general contractor often needs to obtain various information during project management. After merging submodels, the general contractor expects to quickly summarize the general information on labor, materials, machinery, and other resources. This requires suitable information storage and indexing strategies for rapid search. Most backends use a relational database to store BIM and additional application information. The representative format of IFC is object-oriented. If the IFC objects are stored directly according to their structure, information exchange becomes convenient, but real-time search and query from BIM software will become dubious [6].

After subcontractors submit their submodels, there are massive model changes in the deepening design, subsequent construction cost, material procurement, and construction plan [7]. Therefore, the general contractor hopes to obtain the changes between old and new models, including the contents and the reasons for changes. Among them, the reasons for changes are more critical, and the general contractor will screen and classify accordingly and send the changes to the department for further processing. In addition, the entities of the IFC model have well-defined metadata structures [8]. Therefore, more meaningful detection results will be given if taking full advantage of this structure.

Problem: Referring to existing model storage and indexing methods, time consumption originates from searching and joining many tables. This leads to low efficiency when retrieving entities in an IFC-based database. For example, data from geometry and resource tables must be queried to extract the information of a beam instance. In addition, existing methods cannot classify model changes by the cause of changes, which makes it difficult for users to obtain helpful information [9]. Many insignificant small changes make it hard for users to locate the changes they care about. For example, hundreds of air conditioning pipes are connected. If one pipe changes, it will change other related pipes through relational entities. But these relationship changes should not be reported when doing quantity takeoffs.

2. Related Works

Similar studies on merging, extraction, and information acquisition of IFC or BIM exist. Some related works are compared in Table 1.

Table 1 

A nonexhaustive list of related works.

The most significant gap in the existing research is that they focus on software engineering but do not emphasize the application of general contracting. More papers discussed merging external information into BIM [16, 17], dealing with various data formats like JSON, images, and OBJ [18]. Merging one submodel into another model seems less concerning. The general contractors hope to solve inconsistency from subcontractors’ submodels. The merging problem is caused by management naturally, not by software barriers. The same gap exists in model extraction methods, mainly geometric or topological data extracted for other calculation software [19, 20], but few focus on an entirely usable model for subcontractors or department users. As for information acquisition, the need for general contractors was only partially satisfied.

There are reports of various cloud-based approaches to address the storage and search of large-scale IFC models [14, 21]. Based on the cloud storage framework, it is easier to manipulate BIM entities among different remote stakeholders and execute intelligent queries on the server side. However, little research has been done to optimize resource information storage (labor, materials, machinery), which is more concerned by general contractors. Some new change detection algorithms were proposed. For example, IFCdiff [9] and the IFC hash acceleration [15] both reported significant improvement in time complexity and accuracy. However, again, these researchers focused on optimizing computing algorithms, not digging into the root cause of changed contents. Therefore, it remains a problem for general contractors to classify changes that matter to different subcontractors.

3. Methodology

3.1. IFC, Model View Definition (MVD), and Other Related Concepts

IFC standard, particularly the IFC4 version, is an open and standardized data storage format for building lifecycle modeling. Popular BIM modeling software support exporting IFC-format files for storage and exchange. IFC represents data in an object-oriented manner and stores various building components and their relationships with instances of various types of IFC entities. Each IFC entity has many attributes for storing information about building components.

The submodel is a subset of the IFC model. In digital construction scenes, it is necessary to extract a simplified submodel for a specific construction process or an area of particular concern. A standard format defines the submodel–MVD, which is a combination of some entity restrains and some instance filtering conditions [22], usually appearing as an independent eXtensible Markup Language text file [23].

Next, some technical terms of IFC are briefly introduced. IFC entities can be divided into independent exchangeable entities and nonexchangeable (resource) entities. With the globally unique identifier “GlobalID,” exchangeable entities can be retrieved, extracted, and shared separately. Resource entities only have temporary IDs and cannot be independently extracted and shared between different software. Independent exchangeable entities have complex inheritance trees and form the central part of the IFC scheme.

“Process entity” and “product entity” belong to the basic entities in the independently exchangeable entities. Process entities describe the process, task definition, and schedule information in construction management. Product entities describe physical components in buildings, such as beams, columns, walls, etc., including geometric and nongeometric attributes [24].

Another kind of “relational entity” amongst independent exchangeable entities describes the relationship between basic entities. The relationship between basic entities cannot be established through direct mutual reference but must be connected through relational entities. This makes the entity-relationship clearer and can be adequately used. A relationship entity records the relationship between an entity E (called “primary entity”) and a set of entities Bs (called “secondary entity set”). Accordingly, entity E owns a “reverse attribute” pointing to all related entities related to itself.

3.2. Method Framework and Novelty

As shown in Figure 1, this paper proposes solutions to address the problems mentioned above that general contractors will face in digital construction. First, the IFC standard lays the foundation, and BIM data are represented by IFC. Then two core problems about establishing BIM are solved based on MVD: submodel merging and extraction. After that, two information acquisition methods are provided, as complementary approaches, to help better utilize BIM for general contractor companies. The model indexing method helps to search and summarize project resources sufficiently, and the change detection method helps compare models before and after submodel merging.

Figure 1 

The framework of the proposed method.

There are some novelties achieved from the proposed method: (1) a submodel merging method is proposed to support the continuous merge of submodels created by different users and help establish a complete digital construction model. The method also solves the problem of possibly incomplete or inconsistent data. (2) An instance-level model extraction method based on the characteristics and strong correlation of various entities in the model is proposed to ensure that the extracted instance set is the minimum submodel to meet the use requirements. (3) A model storage method is designed to meet the needs of rapid data retrieval. Then a new IFC model change detection method based on object metadata is provided, which can give the causes of changes and improve efficiency.

4. Consistent Merge of Design Models

This section describes the proposed BIM model merging method based on IFC and MVD. The overall logic of this method is illustrated in Figure 2. The proposed method can maintain the model’s integrity by merging models from different stakeholders with the original design model.

Figure 2 

The processing logic of submodel merging.

Step 1:Make an entity list L₀ of the submodel: from the IFC preliminary design model (the starting point in Figure 2), extract the required IFC submodel M₀, including the IFC instance list L₀ = {e_t, {o_tj}}, where e_t is the IFC entity name, and o = {o_tj} is the collection of IFC instances with entity type e_t.Step 2:Read the modified IFC submodel and create instance list L₁: read in the IFC submodel M₁ to be merged, and similarly establish the IFC instance list L₁ = {(e_i, {o_ij})}; at the same time, read the MVD as V = {e_m}, where V describes those IFC entities to be merged in L₁.Step 3:Calculate the IFC instance list L₂ to be merged: traverse each class e_m in V. Then extract all instances {o_mj} under the class e_m from the instance list L₁ of M₁, and compose the instance list L₂ = {(e_m, {o_mj})}. If L₁ does not contain the element under e_m, an empty pair (e_m, {}) will be added to L₂. The IFC submodel M₂, a subset of M1, has been established and is ready to merge with MC.Step 4:Analysis of the modification status of IFC instances: in this step, L₀ and L₂ are compared to classify instances by four modification statuses: deleted, added, refreshed, and unchanged. First, for each (e_i, {o_ij}) in L₀, find (e_m, {o_mj}) in L₂, where e_i = e_m. If o_ij has no GlobalID match in {o_mj}, it is marked “deleted” and put in {o_mj}. Then, for each (e_m, {o_mj}) pair in L₂, find (e_i, {o_ij}) pair in L₀ where e_m = e_i. For each o_mj, if it has no GlobalID match in {o_ij}, it is marked “added.” But when a GlobalID match can be found, the OwnerHistory is compared. If they have inconsistent OwnerHistory, o_mj is marked “refreshed;” otherwise, “unchanged.” Finally, if e_i cannot be found in the first place, {o_mj} will all be marked “added.”Step 5:Recover information of entities in the submodel: this is the most critical step to avoid incomplete data and maintain the model’s integrity. Referring to Figure 2, some entities are probably missed from M_C to M₀, which means M₂/L₂ is incomplete. Therefore each (e_m, {o_mj}) in L₂ is recovered as follows. If e_m is an IFC basic entity, its relationships should be recalculated to recover its reversed attributes. If e_m is an IFC relationship entity, its related entities should be recalculated to recover its secondary entity set. Details of this process are shown in Figure 3.Step 6:Merge M₂ into M_C: M₂/L₂ is now ready to be merged into the preliminary M_C model. For every (e_m, {o_mj}) pair in L₂, find (e_k, {o_kj}) in L_C where e_k = em. If one cannot find any e_k, (e_m, {o_mj}) should be directly added into L_C. After that, each o_mj is processed by its modification status. If o_mj is marked “added,” it will be directly added into {o_kj}. If o_mj is marked “refreshed,” it will replace the instance with the same GlobalID in {o_kj}. If o_mj is marked “deleted,” the instance with the same GlobalID in {o_kj} will also be deleted. Those “deleted” instances are invisible in BIM software.

By recording the instance list of extracted submodel, the instance modification status of the IFC submodel is analyzed, especially to merge the “added,” “deleted,” and “refreshed” status into the preliminary model.

Figure 3 

The flow of recovering information of entities in submodel.

5. Minimum Usable Submodel Extraction

Theoretically, the elements in the BIM model are all interrelated, so additional relevant instances must be added when extracting the submodel. But the amount of additional instances is challenging to determine. The final result’s size will be too large to use if too many related entities are extracted. On the contrary, there may be missed but valuable instances. As mentioned, the result of class-level extraction always contains redundant objects. This section proposes a new extraction strategy by the “core instance” concept to obtain a minimum usable instance-level model.

The submodel M is extracted from the original model M₀.Step 1:Read the MVD as V = {e_m}, where V describes IFC entities to be extracted. Then read the filter conditions of instances as T = {t}, which gives instance-level rules. A filter condition t is expressed as (te, tp, tv), where te, tp, and tv are the entity name, property name, and expected property value, respectively.Step 2:Extract the core instance set of M as E_c. For each instance E in M₀, when E∉V, it will not be extracted as E_c. If E∈V, search all filter conditions. When there exists a filter t = (te, tp, tv) such that te is the entity name of E and E.tp = tv, E is extracted to E_c. If no filter is found, E is directly added in E_c. For example, as shown in Figure 4(a), the group of te1-1–te1–5 are filtered instances under t1 and another condition t2 filters the group of te2-1–te2–3.Step 3:Expand the core instance set. For each core instance C, traverse all C’s reverse attributes and find product entities directly related to C. Put relationship entities and product entities that pass MVD into E_c. For example, as shown in Figure 4(a), E₁ and E₂ are related to te1-1 through R₁; therefore, E₁, E₂, and R₁ are added into submodel M.Step 4:Consider each group of instances filtered by the same condition, such as te1-1–te1–5 in Figure 4(b). Some core instances are linked by relationship entities, thus forming a graph structure. Between each pair of core instances in the group, if a path does not exist, find the shortest path and add all instances on the path to M. For example, there is no path between te1–2 and te1–3, but E₃ can link them through related entities. Therefore E₃, R₃, and R₄ are extracted into M.Step 5:Extract possible relationships between groups. For every pair of groups P and Q, if an instance from P can connect to an instance from Q with only one relationship entity r, the secondary entity set of r is extracted into M. As shown in Figure 4(c), since R₅ directly connects E₄ and E₅, R₅ and its secondary set member E₆ are extracted.Step 6:Fill necessary resource entities into instances in M.

Now M is the minimum submodel from M₀ defined by MVD and filter conditions T.

Figure 4 

Main steps of finding extracted instances.

This method focuses on MVD, filter conditions, and core instances, proposing clear rules to extract an appropriate number of relevant instances, which brings two apparent benefits: (1) unnecessary instances are filtered according to IFC metadata definitions to ensure that the final result is minimal and (2) it can extract qualified instances and other strongly related instances as well. This ensures the submodel information is complete and rich in meeting on-site use needs.

6. Fast and Accurate Information Acquisition

6.1. Relational BIM Storage and Indexing Method for Rapid Search

To address the problems mentioned in Section 1, a model storage method is designed to efficiently store model data from IFC and improve efficiency during data search. First, according to the metadata of entities in IFC models, different kinds of storage tables are established respectively for a basic entity, relationship entity, and resource entity. Then some indexing tables are precalculated for search requirements. The detailed algorithm is listed in Appendix A, which features the following advantages:(1)The attribute information of each independently exchangeable instance is stored in the same table, so there is no need to retrieve data from many resource entity tables during data extraction.(2)For relational entities and reverse attributes of the base entity, only the entity name and GlobalID of the base entity in the attribute value are stored, which enables a fast query of the relationship between the base entities and avoids duplicate storage of the base entity data.(3)Toward the need for rapid search to the attributes of resource entities, indexing tables are established in advance, avoiding traversing multiple tables. On average, indexing tables will occupy 5% of space, but its query is 10 times faster than table join.

6.2. Reason-Rich Model Change Detection

A change detection method for IFC models based on object metadata is proposed to solve the unreliability and low efficiency of component change detection between different versions of BIM models. The detailed algorithm is listed in Appendix B. The proposed change detection method can detect changes such as component, type, property set, as well as the relationship between components. In addition to changed contents, the profound reason for changes can be reported, which enriches the semantics of detection results. The reason for changes helps the general contractor to classify numerous changes and focus on changes that matter. This method can also avoid the error result caused by circular references.

7. Case Study

7.1. Case Overview

The proposed IFC-based solutions were tested in a large airport terminal project in South China.

This airport terminal consists of five floors above the ground and three floors underground, with more than 210,000 square meters of the construction area. In this case, the application scenarios of digital construction are distributed from the deepening design phase to the early stage of the construction phase.

The digital construction model involved was the first and second floors of the main terminal building. Since the project’s steel structure, mechanical system, and construction process were quite complex, digital design technology was adopted in the preliminary design stage. After a detailed preliminary design model was delivered, the solution package proposed in this paper was used in several key scenarios to establish deepening design BIM and better utilize models in subsequent stages.

The application process is shown in Figure 5, which takes the construction section of the check-in island on the second floor as an example. First, the preliminary design model was divided into several professional submodels through several MVDs and delivered to each deepening design group for design work, including structure, mechanical pipeline, equipment installation, water supply and drainage, architecture, and other majors. In this process, the general contractor required important changes between the final version of the structural deepening and a previous version, so the change detection algorithm was adopted. Next, the professional models are merged into the primary model by the BIM consulting team, which involves a consistent integration scenario. Then, after collision detection, verification, and approval, the BIM database was established through the proposed model storage method and several indexing tables. Finally, several submodels are extracted from the BIM database to use the digital model during construction, such as steel columns with working schedule information for the steel installation team. And all mechanical pipes and equipment for the mechanical subcontractor on the second floor. The following section describes the case application with several examples and a performance analysis.

Figure 5 

Application flow in the airport terminal project.

7.2. Digital Construction Scenarios and Applications

7.2.1. Design Submodel Merge

During the model merge scenario of deepening design submodels, the IFC instances were analyzed in steps according to Section 3.1. The original primary design model MC describes electric components and a sequence of working steps to install them, including 21 IfcTask instances, 374 IfcProduct and its subclasses, 42 IfcTask instances, and their IfcRelationship instances. For example, the model includes IfcTask instances “compass box air duct,” “cable tray,” “fire hydrant box installation,” and their related components. Parts of the extracted instances in M0/L0 are as follows:

(IfcTask, {IfcTask12# (compass box air duct), IfcTask34# (cable tray), cabinet), IfcTask7# (fire hydrant box), …})

(IfcDuctSegment, {IfcDuctSegment1# (cable tray-ceiling), IfcDuctSegment2# (cable tray-underground), …})

There are some relationship instances under IfcRelAggregates, IfcRelAssignsToTask, and IfcRelSequence.

After the deepening design phase, the mechanical submodel with schedule (progress information) was about to merge into M₀. Read in the IFC submodel M₁ as list L₁ = {(e_i, {o_ij})}. Table 2 lists some typical modifications in M₁. The corresponding MVD is V = {e_m} = {IfcTask, IfcDuctSegment, IfcRelAggregates, IfcRelSequence, IfcRelAssignsToTask}. According to the proposed method, L₂ with To-merge instances and their modification status was calculated in Table 2 as well.

Table 2 

Some examples of modifications and analysis.

For those added instances, such as IfcTask1# and IfcRelAssignsToTask3#, there are no related instances in M₀; thus no need to recover. For deleted instances, their information would be ignored. However, some modified instances should be recovered on their attributes. For example, there are some relationship instances from the primary model but not in M₀/L₀ relating to IfcTask12#, so three IfcRelAssignToControl are added to reversed attribute HasAssignments, and one IfcRelNests was added to reversed attribute Nests. Another recovered instance was IfcRelAssignsToTask34#. In addition, a slab in M_C was not extracted to M₀, and an IfcSlab was added to the secondary entity set.

Finally, merge M₂ to M_C: (1) add all new instances to M₀; (2) use modified instances to replace original instances in M₀; and (3) find deleted instances by GlobalID and set their OwnerHistory to “deleted.” After any submodel merge event, M_C was able to remain consistent and complete.

The method uses MVD and metadata of secondary entity set and reversed attributes to avoid merging redundant IFC entities. In the project, redundant entities were no more than 5% in the primary model. In addition, the problem of incomplete data caused by modified instances was avoided. The general contractor validated the information integrity rate as greater than 95%.

7.2.2. Model Storage and Indexing

After the final deepening design model was established by merging, it was stored in a database according to the proposed storage and indexing method. Figure 6 shows an example of a fragment of an IFC file.

Figure 6 

The partial structure of an IFC file.

Exchangeable entities were first stored in separate tables. Then, all beams (including 3#) were stored in the beam table as in Table 3.

Table 3 

Column structure and values of beam table.

Then, some indexing tables are calculated based on management requirements. For example, during schedule management, the executor information of a construction task is important. Therefore some rapid search requirements for all team leaders are proposed, for instance, 10#. The database created an indexing table I_PERSON, storing the ID and name of 10#. Then find all instances that quoted 10#, which is #11. Similarly, find that #9 quoted 11#, and {1#, 2#, 3#} quoted 9#. Finally, a row in the I_PERSON table stored information as Table 4.

Table 4 

Column structure and values in the indexing table.

Now important exchangeable instances can be obtained in one single query, which is much faster than traditional database table joins. The manager of a general contractor can easily search for schedules and jobs of a particular work team and then calculate their progress. In Table 5, the search performance of the database search and our method were compared on three requirements. It is clear that the indexing table saved 90%–92% resource search time and behaved better when the results became larger. Although the index tables for common resource entities occupied extra space, we found that less than 10% of space was needed.

Table 5 

Performance of indexing tables.

7.2.3. Reason-Rich Change Detection for Different Department Users

As mentioned, the project’s general contractor often checked the difference between the two versions of detailed design models to understand the modifications of the design drawing. The proposed method can detect the changes in components, progress, and attribute set and give the reasons for the differences. This has brought great benefits to the on-site managers. In the past, many changes were detected through the direct comparison of the database, which wasted much labor to manually choose the important differences. Now one can choose the type one care about and check for exciting changes. According to the proposed method, change detection results on the overall model are shown in Figure 7, where R, P, T, and E denote relationship, property set, types, and entities, respectively. Arrows indicated the cause of changes. More than 4,000 detected changes from nine kinds of causes, among which modified product entities were important. However, different departments of the general contractor emphasized different aspects of changed entities.

Figure 7 

Numbers of detected changes and corresponding departments.

(1)The progress management department: their work was to check all component entities and progress information. Therefore, the changes in association relationships were crucial because they would affect the organization sequence and schedule of construction. Progress managers should focus on reviewing those models changed by relationship changes between components and tasks. As shown in Example 1 in Figure 7, the order of “cable tray installation task” and “fire hydrant installation task” was swapped. So there were two task changes caused by a change of relationship entity. The general contractor would send this change information only to the progress department. Because no components or geometry had been changed, other departments or subcontractors did not need to deal with these changes.(2)Mechanical construction subcontractor: the relationship between components in the model was less important so that the relationship change will be ignored. They paid more attention to the components that change due to the difference of property set because it will affect the model information of equipment installation, the material of pipes, etc. As shown in Example 2 in Figure 7, the material of cable trays was changed from aluminum alloy to galvanized steel. So there were 15 cable trays changed because of one change of material property set. These changes significantly increased the overall budget of the mechanical equipment. The general contractor would send these changes to the mechanical subcontractor and budget managers but not other irrelevant stakeholders.

7.2.4. Usable Submodel Extraction

There was a great demand for submodel extraction in the construction phase of the airport terminal building. Before a construction task, the work contents of a team were extracted from the original model, including component entity, spatial relationship, size information, workflow breakdown, etc. Then use the extracted model to disclose to the construction team so they can quickly understand the upcoming jobs. Therefore, model extraction requires comprehensive and complete information. In addition, it is also necessary to provide relevant partial models for each subcontractor to carry out cost management or export their drawings. These models should exclude irrelevant entities and avoid including the information of other subcontractors as possible.

According to Section 6, the following two models are used to extract requirements as examples. The first requirement was “all steel components at the ceiling of the check-in zone.” The components involved were a small number of structural components but contained complex IfcTask entities. The second requirement was “mechanical units and pipes on the 2nd floor installed by Company X,” involving many interrelated electromechanical pipelines and equipment, and it is required to exclude the model information of other subcontractors.

Compared with the general IFC text matching method or cross-table join operation in the database, the proposed method can consider the integrity and result volume by focusing on core entities, expanding and supplementing the strongly related entity information. Tables 6 and 7 show the comparison of the method proposed in this paper with other methods and the comments of field workers about the usability of the model. The proposed method can obtain the submodels in no more than two times the time consumption, acceptable for field use. The advantage of the proposed method became more evident when the extracted model was complex. In addition, the extraction results rarely contain redundant entities, so the size of the result remained about 10%–40% smaller than the database join.

Table 6 

Performance of model extraction on requirement 1.

Table 7 

Performance of model extraction on requirement 2.

8. Discussion and Conclusion

Aiming at the problems and difficulties of three key scenarios for the general contractor in the digital construction process, this paper proposed four solutions to better establish and utilize BIM. The algorithms of these solutions depended on the widely used IFC standard, which ensures the universality of our method. During various stages of digital construction, it is difficult to ensure consistency by integrating models in the preliminary and deepening design stages, while some information about related entities may be lost. The proposed model merge method ensured consistency before and after fusion by analyzing the modification state of individuals and incrementally recovering the information associated with entities. Then, in response to the massive need for instance-level submodels, a minimum model extraction algorithm was proposed to extract strongly related model information required by users. Irrelevant entities will be eliminated at the same time. Therefore, the extracted submodel was accurate and met the user’s needs. After establishing consistent BIM and submodels, how to utilize the model information was the third scenario. The proposed new model storage method reduces a lot of cross-table searches via the BIM database, improves the efficiency of obtaining model information, and realizes the rapid search of information through index tables. In addition, the extraction results of the model were simplified under constraints from MVD. In the deepening design phase, model change detection with semantic results enables managers to find important and concerning changes pertinently and avoids retrieving unnecessary information.

This paper’s advantage is providing better digital services for all participants of large-scale projects from the perspective of general contracting. The solutions had been applied in a large-scale construction project, and the performance was summarized. As a result, the departments of the general contractor company and subcontractors validated two significant benefits as follows:(1)By applying the method of establishing BIM, the correctness and consistency of general contractors are improved. Model merging ensures that all entities in the design model are of no repetition or omission. The results obtained through submodel extraction are also independently suitable for subcontractors’ use. Therefore, BIM technology plays a vital role in modern design and construction.(2)It is more convenient for on-site general contractors to utilize BIM information, reducing manual labor and improving production efficiency. Retrieving resource information from the BIM database became more efficient. When facing many model changes, one can use the change reasons to locate interesting components and filter irrelevant information. Generally speaking, practitioners have introduced digital construction into the traditional workflow and gained benefits, so they are more willing to use new technologies, forming a virtuous circle. This benefit also promoted the digitization transformation of the construction industry.

On-site applications have proved that the proposed method can support key scenarios in digital construction workflow. However, there are still some known limitations of the proposed methods. Future research may include the followings: (1) although IFC is a widely supported data standard format, the IFC exported by current digital construction software will still lack information. Therefore, getting through the integration and change detection from software to software is worth studying. (2) There is a lack of suitable methods to deal with users’ custom IFC extension entities. (3) On the computing side, the proposed algorithm still involves many intensive calculations, such as path searching, so the speed performance may be further optimized by the cloud BIM computing framework.

Appendix

Appendix A. The detailed algorithm of model storage and indexing

Traverse each instance E in the IFC model and decide subsequent steps by E’s metadata.

A.1. Case 1: E Is an Instance of a Basic Entity

Step 1:Find the corresponding data table T_p based on the name of an entity. Add a row to the table and store the value of GlobalID.Step 2:Iterating through each attribute A of instance E, storing the attribute’s value in the A column. If the value of an attribute is a complex IFC instance (not a simple number or string), the binary sequence of this complex instance is directly stored instead of just an ID. When visiting the attribute, the binary sequence will be deserialized into complete information of the instance. This strategy avoids massive cross-table searches and improves efficiency.Step 3:Iterate through each reverse attribute V of instance E, storing the instance name and GlobalID of the reverse attribute in the V column.

A.2. Case 2: E Is an Instance of a Relationship Entity

Step 1:Find the corresponding data table T_r based on the entity’s name. Add a row to the table and store the value of GlobalID.Step 2:Iterating through each attribute A of instance E, storing the attribute’s value in the A column.Step 3:Store the entity name and GlobalID of E’s primary entity (instance of base entity) as two strings in the “cra” column.Step 4:Store entity names and GlobalID of each instance in E’s secondary entity set (set of base entities) as a list of string pairs in the “crb” column.

A.3. Case 3: E Is an Instance of a Resource Entity

Before data storage, some standard search requirements for resource entities are determined by a list Zs = {z_si}, z_si = (z_name, z_pname), where z_name is the resource entity name and z_pname is the index attribute name of the zname entity.Step 1:According to the search requirement list, some “indexing tables” called T_z are established to store index data of necessary resource entities. The name of an indexing table is the resource entity z_name. Then create a GlobalID column, a column named by z_pname, and a column “cze” to store all related instances.Step 2:Traverse each resource instance E in the IFC model. If any z_name in Zs equals E’s name, a row is added in the table z_name to store E. The temporary ID of E is put into the GlobalID column.Step 3:Find all instances F = {f_i} that quote E. In other words, there exists an attribute of f_i equals E. Most instances in F are independently exchangeable entities, but some are resource entities.Step 4:Enter a recursive process shown in Figure 8. For each resource instance f_i in F, find all instances Fʹ that quote f_i, and replace f_i with Fʹ. Finally, all instances in F are exchangeable entities.Step 5:Store the entity names and GlobalID of instances in F as a list of strings in “cze” column. This allows for finding related exchangeable entities within one single query.

Figure 8 

Recursive process of finding related exchangeable entities.

Appendix B. The detailed algorithm of change detection

IFC models A and B are compared. Take model A as a benchmark. Changes made in model B will be detected.Step 1:Extract component instance set E_a (under IfcObject), component type instance set T_a (under IfcObjectType), extended attribute instance set P_a (under IfcPropertyDefinition), and relational instance set R_a (under IfcRelation) from IFC model A. Similarly, extract E_b, T_b, P_b, and R_b from IFC model B.Step 2:Based on the ID and attributes of the instance, calculate added component set E_add, deleted component set E_del, modified component set E_mod, and unchanged component set E_unc. First, only compare GlobalID and get E_unc = E_a∩E_b, E_add = E_b−E_unc, E_del = E_a−E_unc. Then compare simple attributes (only numbers and strings) in E_unc. If instances o_a and o_b has the same GlobalID but differ in any attribute, move o_a into E_mod.Step 3:Calculate all component instances E_type associated with T_add, T_del, and T_mod. Then calculate modified component instances because of type modification: E_t = E_unc∩E_type. Remove E_t from E_unc and add E_t to E_mod.Step 4:For T_a and T_b, use the same method to calculate added type set T_add, deleted type set T_del, modified type set T_mod, and unchanged type set T_unc. For P_a and P_b, similarly calculate added property set P_add, deleted property set P_del, modified property set P_mod, and unchanged property set P_unc.Step 5:Calculate all component instances E_pro and all type instances T_pro associated with P_add, P_del, and P_mod. Then calculate type instances modified because of property modification: T_y = T_unc∩T_pro. Next, remove T_y from T_unc and add T_y to T_mod. Then calculate all component instances E_pt associated with T_y. Next, calculate component instances modified by property modification: E_t = E_unc∩E_pr∪E_pt. Finally, remove E_t from E_unc and add to E_mod.Step 6:For R_a and R_b, calculate added relation set R_add, deleted relation set R_del, modified relation set R_mod, and unchanged relation set R_unc.Step 7:Let E_r be modified component instances because of relationship modification. Initialize E_rm = Ø. For each relation, R in R_add and R_del, add R’s primary entity and secondary entity set into E_rm. If the primary entity is modified for each relation R in R_mod, only add R’s primary entity into E_rm. But if the secondary entity set is modified, only those different instances in the secondary set are added to E_rm.

Finally, calculate component instances modified because of relationship modification: E_r = E_unc∩E_rm. Remove E_r from E_unc and add E_r to E_mod.

Now all modified instances can be output with detailed information about why they are changed.

Data Availability

The data used to support the case study are available from the corresponding author upon request or download from open data on the product website: https://www.ibuildingsh.com.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This work was financially supported by the Shanghai Science and Technology Innovation Action Plan project (22dz1207102), the Shanghai Outstanding Discipline Leader Program (22XD1432000), and the Innovation Project of Shanghai State-owned Assets Supervision and Administration Commission (2022008).