# An IDM-Based Approach for Information Requirement in Prefabricated Construction

Authors: Zhao Xu; Jimmy Abualdenien; Hao Liu; Rui Kang
Journal: Advances in Civil Engineering
 (2020)

---

## Abstract

Prefabricated construction promotes providing better productivity and project results. Building models, including their elements’ fabrication details, are complex structures that need accurate information delivery among the project participants and their partial designs. This paper extends the IFC data model to support prefabricated construction. Also, it discusses the advantages of systematically managing exchange requirements in a database to facilitate generating IDM (Information Delivery Manual). The paper first introduces a BIM-based collaborative work mode by sharing and extracting the model views. The core of the sharing is the establishment of view exchange standard about the linked model and the definition of exchange requirements based on the design process, leading to the formulation of the IDM standard again from the perspective of the actual design. Process maps covering architecture, structure, plumbing, mechanical engineering, and electrical engineering are made to show how to realize BIM-based collaborative work. Then the exchange requirements referred to the object and attribute of the BIM model which should be delivered in a special phase are defined in particular tables. To facilitate the automation of managing and exchanging requirements, a database management system is designed with its corresponding user-interface, which enhances the collaboration and delivery throughout the project life cycle. The proposed approach supports better information reuse and delivery among the project participants.


---

## Body

## 1. Introduction

The prefabricated construction is interdisciplinary and involves complex products and processes. Unlike traditional cast-in-situ methods, prefabricated construction produces building components at a manufacturing facility and then transports entire components or semicomponents to the construction site for assembly [1]. Although its adoption at times can increase construction costs [2], prefabricated construction has been endorsed as a “cleaner” approach due to its ability to reduce construction waste, noise, dust, labor demand, and resource depletion, as well as increase safety management [3]. However, the coordination and share of the prefabricated construction information has always been one of the most challenging tasks encountered in the delivery process [4]. On the other hand, the current construction delivery model does not support prefabricated construction techniques due to extensive project information involved, even though prefabricated building technologies offer tremendous advantages to the construction industry [5]. The design and construction of prefabricated construction is a multidisciplinary complex process that requires a seamless coordination and exchange of requirements.The adoption of the building information modeling (BIM) paradigm in the Architecture, Engineering, and Construction (AEC) industry is increasing [6], as it improves the process’ efficiency and quality by promoting the early exchange of 3D building models. Using BIM, the collaboration between the various disciplines is based on exchanging semantically rich 3D building models, which is a significant improvement over the traditional exchange of 2D drawings. BIM aims at providing a shared digital foundation for the diverse kinds of information needed throughout a building project’s life cycle [7]. Building information modeling (BIM), being a transformative technology in the construction industry, will bring not only the change of design tools and models but also a comprehensive range of information revolution on the delivery, extraction, and use of information in the construction sector. For exchanging the building information among different BIM-authoring tools, the Industry Foundation Classes (IFC) is an open standard that includes data specifications for the individual building elements and their relationships. However, different researchers have identified the inflexibility of providing IFC data from the BIM-authoring tools to support the diverse use-cases needed during a construction project [8, 9]. As a solution for this inflexibility, the Information Delivery Manual (IDM) and the Model View Definition (MVD) approach were proposed by the building SMART to provide a common understanding of which information should be present in the export IFC model for a particular use-case. MVD here is a subset of the overall IFC schema to describe a data exchange for a specific use or workflow [10]. Through the development of an IDM, the actual workflow and the required interaction among the different disciplines are explicitly defined. The Information Delivery Manual (IDM) methodology assists the communication and collaboration among the various domain experts throughout the project life cycle. The IDM provides a framework for the creation and maintenance of BIM object data to be included within the stakeholders’ requirements [11].The integration of prefabricated construction and IDM enhances the level of information delivery. It is worth noting that prefabrication has been widely adopted worldwide, especially in China, Japan, and Singapore, which makes use of variable types of precast elements, including precast façade, semiprecast slab, volumetric precast bathroom, tie beam, staircase, parapet, refuse chute, half landing, water meter room, lift machine room and main roof slab. However, the well-formatted information of prefabricated component at the right time in the right location is still insufficient to further raise the efficiency of collaborative working and decision making when adopting BIM in prefabricated construction projects [12]. The AEC industry demand for developing specialized IDMs is high; currently, there are around 128 IDM documents with different statuses (a draft, proposal, approved, idea, work in progress, paused, and on hold) on buildingSMART [10]. However, practitioners have identified the involved complexity of developing an IDM starting from specifying the process map, typically using the Business Process Modeling Notation (BPMN), to collecting and defining the required information for different building elements [8]. Additionally, it is impossible to track and reuse existing exchange requirements (ERs), Functional Parts (FPs), and MVDs [8].Although the emerging industry problems and the increasing life-cycle participation emphasize the importance of the information delivery, the BIM-based information delivery platform for the prefabricated construction management has not developed radically recent years. To address this challenge, this paper develops an IDM-based methodology for better information delivery in prefabricated construction. The proposed methodology extends the IFC data model for prefabricated construction, identifies the stakeholders’ information requirements, integrates the developed information delivery ontology in prefabricated construction with the IDM standard, and manages it in a database. It allows for (1) expressing the attributes of prefabricated components in IFC format which can be universally exchanged, (2) sharing and reusing the delivery information required in prefabricated projects, and (3) managing the information delivery process systematically and automatically. With this methodology, a BIM-based collaborative information delivery platform for prefabricated construction can be built. The proposed methodology was evaluated in a prefabricated reinforced concrete frame building model.The rest of this paper is organized as follows: Section2 presents the state of art relevant to information delivery process in prefabricated construction. Section 3 describes the whole methodology used while conducting this research. Section 4 introduces the developing of the IDM for design process in prefabricated construction. Section 5 provides a database management system for information exchange based on the developed IDM. Section 6 evaluates the proposed IDM approach with a prefabricated reinforced concrete frame building model. Section 7 discusses the limitations and future work of this research. Finally, the paper ends with some concluding remarks.


## 2. Literature Review

### 2.1. Information Delivery Systems

BIM technology has led to the transformation of paper documents into digital documents, at the same time bringing new problems in information delivery. Although IFC schema provides an inclusive data model that covers multiple use-cases, it is still incapable of supporting the exchange of building information as needed by other various disciplines. The emergence of Information Delivery Manual (IDM) provides a solution to this problem. IDM has developed a set of standards that define the actual workflow and the information required for the interaction. Meanwhile, Model View Definition (MVD) is proposed to implement the information exchange requirements of the IDM and to verify whether the derived information conforms to the standard.On this basis, various researchers are investing in information delivery systems. For the Heating, Ventilation, and Air-Conditioning (HVAC) fields, hundreds of algorithms are used to analyze its performance, which generates lots of complex information. Liu et al. [13] proposed an IDM extension approach to identify the information requirement and map these multiple information sources. Pinheiro et al. [14] propose a standardized method of information exchange between Building Information Modeling (BIM) and building energy performance simulation (BEPS) tools using the Information Delivery Manual (IDM) and Model View Definition (MVD) methodologies. At the same time, information delivery also plays an important role in the life cycle management of both architecture engineering and infrastructure. Using mixed modes of information delivery, Rezgui et al. [15] proposed a governance approach for BIM management across the building life cycle. IDM is also used in a new bridge inspection system called SeeBridge as a necessary component [16]. The above research proves the practicality of the information delivery system, and further research into the application of information delivery systems in the field of practical engineering is also underway.


### 2.2. Information Delivery in Prefabricated Construction

As a different construction method from traditional cast-in-place, prefabricated construction is getting more and more attention. Research has proved that prefabricated buildings can not only improve the efficiency and quality of engineering construction but also have the advantages of comprehensive cost reduction, energy saving, and environmental protection [17]. However, in the actual application process, there are still some problems in the assembly of the prefabricated construction and the building model. In the architecture design process, prefabricated construction is always separated out and has difficulties in collaboration with other disciplines. To overcome this problem, information delivery plays a vital role. To take full advantage of BIM, Ramaji and Memari [18] proposed a method to standardize the information exchanges of prefabricated construction, where a complete IDM is established to present the whole process of information exchanges with abundant details, which makes the information delivery in prefabricated construction clearer. Besides the information exchange standardization for prefabricated construction, Ramaji and Memari [19] extended an MVD to support multistorey modular building and made it available to applicate from architecture to structure. Although there are related researches on information delivery of prefabricated constructions, they are not as many as other disciplines have. There is still room for improvement and integration into the design and construction processes.


### 2.3. Stakeholder Identification in Prefabricated Construction

The concept of stakeholder was firstly proposed by the Stanford Research Institute that described stakeholders as groups or individuals who mattered a lot for organizational survival [20]. Later, Freeman [20] extended the definition as “those groups who can affect or is affected by the achievement of the firm’s objectives.” Afterward, the stakeholder theory was developed into a descriptive, instrumental, and normative approach [21]. Subsequently, it was brought into the construction management field, and extensive relevant researches emerged. Olander [22] suggested that, for project leaders, it is important to give full consideration to the needs and requirements of their stakeholders. Atkin and Skitmore [23] proposed to address the needs and expectations of stakeholders involved to implement the project completely and successfully. Most of the previous studies emphasized the importance of identifying stakeholders and their requirements in the project.As prefabricated construction technology is becoming more and more popular nowadays, research of identifying stakeholders and their requirements in prefabricated construction has been a widespread topic in construction management. Scholars in this area have conducted some relevant researches on it in recent years. Li et al. [24] categorized stakeholders involved in constructing prefabricated buildings as government, funding organization, consultant, contractor, subcontractor and supplier, and client. Teng et al. [25] used several ways, such as literature review, face-to-face interview, and chain referral sampling, to identify specific stakeholders within the industry chain of industrialized building, which included four main phrases, concept definition phrase, design phase, construction phrase, and in-use phrase, and the relationships between them. Jiang et al. [26] considered stakeholders as six types according to the different attitudes they have, which were developers, designers, contractors, engineers, manufacturers, and property managers, respectively. Gan et al. [27] identified 15 stakeholder groups in off-site construction in detail by literature review and expert interview, including the government, developers, designers, contractors, professional sub-subcontractors, supervisors, manufacturers, researchers, education institutions, consultants, suppliers of equipment and materials, financial institutions, the public, logistic enterprises, and the media. Yin et al. [28] suggested four main kinds of stakeholders in off-site construction in the analysis on BIM-enabled off-site construction, which was designer, manufacturer, construction contractor, as well as maintenance, and operation personnel. However, a research identifying both stakeholders and their requirements in prefabricated construction is lacking, which is what this research includes.Compared to traditional on-site construction, prefabricated construction involves more new stakeholders, such as off-site manufacturers and transporters [29], making the process more complex in respect of project planning, organization, coordination, and communication [30]. Because of the increased complexity, the control of prefabricated projects becomes more difficult, resulting in more inefficiencies and uncertainties. Therefore, prefabricated construction calls for a higher demand in terms of information delivery among stakeholders involved in the process.The existing IDM does not include the requirements of stakeholders in prefabricated construction well. Thus, the main goal of this research is to extend the IDM for prefabricated construction and integrate it into a database, so as to provide effective information exchange to address the low information interoperability [29] and inefficient data integration throughout the process of prefabricated construction.


## 2.1. Information Delivery Systems

BIM technology has led to the transformation of paper documents into digital documents, at the same time bringing new problems in information delivery. Although IFC schema provides an inclusive data model that covers multiple use-cases, it is still incapable of supporting the exchange of building information as needed by other various disciplines. The emergence of Information Delivery Manual (IDM) provides a solution to this problem. IDM has developed a set of standards that define the actual workflow and the information required for the interaction. Meanwhile, Model View Definition (MVD) is proposed to implement the information exchange requirements of the IDM and to verify whether the derived information conforms to the standard.On this basis, various researchers are investing in information delivery systems. For the Heating, Ventilation, and Air-Conditioning (HVAC) fields, hundreds of algorithms are used to analyze its performance, which generates lots of complex information. Liu et al. [13] proposed an IDM extension approach to identify the information requirement and map these multiple information sources. Pinheiro et al. [14] propose a standardized method of information exchange between Building Information Modeling (BIM) and building energy performance simulation (BEPS) tools using the Information Delivery Manual (IDM) and Model View Definition (MVD) methodologies. At the same time, information delivery also plays an important role in the life cycle management of both architecture engineering and infrastructure. Using mixed modes of information delivery, Rezgui et al. [15] proposed a governance approach for BIM management across the building life cycle. IDM is also used in a new bridge inspection system called SeeBridge as a necessary component [16]. The above research proves the practicality of the information delivery system, and further research into the application of information delivery systems in the field of practical engineering is also underway.


## 2.2. Information Delivery in Prefabricated Construction

As a different construction method from traditional cast-in-place, prefabricated construction is getting more and more attention. Research has proved that prefabricated buildings can not only improve the efficiency and quality of engineering construction but also have the advantages of comprehensive cost reduction, energy saving, and environmental protection [17]. However, in the actual application process, there are still some problems in the assembly of the prefabricated construction and the building model. In the architecture design process, prefabricated construction is always separated out and has difficulties in collaboration with other disciplines. To overcome this problem, information delivery plays a vital role. To take full advantage of BIM, Ramaji and Memari [18] proposed a method to standardize the information exchanges of prefabricated construction, where a complete IDM is established to present the whole process of information exchanges with abundant details, which makes the information delivery in prefabricated construction clearer. Besides the information exchange standardization for prefabricated construction, Ramaji and Memari [19] extended an MVD to support multistorey modular building and made it available to applicate from architecture to structure. Although there are related researches on information delivery of prefabricated constructions, they are not as many as other disciplines have. There is still room for improvement and integration into the design and construction processes.


## 2.3. Stakeholder Identification in Prefabricated Construction

The concept of stakeholder was firstly proposed by the Stanford Research Institute that described stakeholders as groups or individuals who mattered a lot for organizational survival [20]. Later, Freeman [20] extended the definition as “those groups who can affect or is affected by the achievement of the firm’s objectives.” Afterward, the stakeholder theory was developed into a descriptive, instrumental, and normative approach [21]. Subsequently, it was brought into the construction management field, and extensive relevant researches emerged. Olander [22] suggested that, for project leaders, it is important to give full consideration to the needs and requirements of their stakeholders. Atkin and Skitmore [23] proposed to address the needs and expectations of stakeholders involved to implement the project completely and successfully. Most of the previous studies emphasized the importance of identifying stakeholders and their requirements in the project.As prefabricated construction technology is becoming more and more popular nowadays, research of identifying stakeholders and their requirements in prefabricated construction has been a widespread topic in construction management. Scholars in this area have conducted some relevant researches on it in recent years. Li et al. [24] categorized stakeholders involved in constructing prefabricated buildings as government, funding organization, consultant, contractor, subcontractor and supplier, and client. Teng et al. [25] used several ways, such as literature review, face-to-face interview, and chain referral sampling, to identify specific stakeholders within the industry chain of industrialized building, which included four main phrases, concept definition phrase, design phase, construction phrase, and in-use phrase, and the relationships between them. Jiang et al. [26] considered stakeholders as six types according to the different attitudes they have, which were developers, designers, contractors, engineers, manufacturers, and property managers, respectively. Gan et al. [27] identified 15 stakeholder groups in off-site construction in detail by literature review and expert interview, including the government, developers, designers, contractors, professional sub-subcontractors, supervisors, manufacturers, researchers, education institutions, consultants, suppliers of equipment and materials, financial institutions, the public, logistic enterprises, and the media. Yin et al. [28] suggested four main kinds of stakeholders in off-site construction in the analysis on BIM-enabled off-site construction, which was designer, manufacturer, construction contractor, as well as maintenance, and operation personnel. However, a research identifying both stakeholders and their requirements in prefabricated construction is lacking, which is what this research includes.Compared to traditional on-site construction, prefabricated construction involves more new stakeholders, such as off-site manufacturers and transporters [29], making the process more complex in respect of project planning, organization, coordination, and communication [30]. Because of the increased complexity, the control of prefabricated projects becomes more difficult, resulting in more inefficiencies and uncertainties. Therefore, prefabricated construction calls for a higher demand in terms of information delivery among stakeholders involved in the process.The existing IDM does not include the requirements of stakeholders in prefabricated construction well. Thus, the main goal of this research is to extend the IDM for prefabricated construction and integrate it into a database, so as to provide effective information exchange to address the low information interoperability [29] and inefficient data integration throughout the process of prefabricated construction.


## 3. Methodology

There are several previous studies that prove the results of using information management in prefabricated construction management [12, 31]. In consideration of prefabricated construction with a large volume of data, information delivery methods and management platform design are advantageous when it comes to related data analysis. IDM is viewed one among them because it could provide means (methods and techniques) for information and knowledge discovery from the databases in order to obtain decision-making support for digitally stored data and is of great importance to organizations.The main purpose of this study is to assist the exchange and delivery of requirements for prefabricated construction. Accordingly, in response to the shortcomings of the traditional process of developing IDMs, which does not have a wide range of compatibility and strong application areas, this paper discusses a systemic way for managing exchange requirements for the different domain experts participating in a construction project. Meanwhile, since traditional IDM has insufficient information storage and cannot use the database to process large data well, this paper establishes an integrated database to enhance information processing and storage.As shown in Figure1, the workflow illustrates the prototypical framework to build the integrated database for information delivery process with the essential data source in an extended IDM approach. The research was based on a comprehensive literature review of the information management in the prefabricated construction and the information delivery methodologies. Based on the knowledge gained from this literature review and the identified gaps, the contribution of this paper lays in proposing an extension to the IFC schema to support the prefabricated construction, presenting an IDM demonstrating exchange requirements among the project participants, and developing a database management system, which makes it possible to define and generate exchange requirements in a systematic way. Then in the Delivery Model part, Requirement Delivery and Data Delivery are carried out to get prepared for subsequent database. On the other hand, extended IDM approach is divided into two steps. In the first step, here is a Process Map proposed to indicate the related parties and the direction in which information flows. Subsequently, Exchange requirement table is offered according to the relative parties and design stage which are shown in the Process Map to detail information exchange. Lastly, in Integrated database part, Conceptual entity model and Data classification and encoding are proposed to form a Relational model. These three parts are finally combined together to implement an integrated database.Figure 1
Research framework.The main issue which is to solve the problem of information delivery requirements is relied on the effective IFC file extension for fabricated elements management and the supplement of an IDM-based description in the databased framework which supports the corresponding operations for the model creator and the model receiver. Firstly, the ontology analysis for information requirements adds the ability to take a piece of element concepts that already exists in the BIM model and put into a unified field related to prefabricated construction. This means any piece of IFC-extended data can automatically be placed into a corresponding information delivery process. Furthermore, the paper discusses the design of classification and encoding approach on the input data of the integrated database which uses the conceptual model proposed in this study for modeling the information delivery among stakeholders to achieve an integrated management of prefabricated construction.


## 4. The Ontology for Stakeholders’ Information Requirements in the Design Process of Prefabricated Construction

### 4.1. Concept Extraction

The Design Process is an approach for breaking down a large project into manageable chunks. Stakeholders such as project managers, discipline engineers, market consultants, and so on use this process to define the steps needed to tackle each project. It consists of six steps: (1) define the problem; (2) collect information; (3) brainstorm and analyze ideas; (4) develop solutions; (5) gather feedback; and (6) improve. As shown in Figure2, each step is interrelated, not isolated. In a construction project, the design process is particularly complex: it involves numerous stakeholders; their requirements must be identified and translated into the process meticulously under a highly dynamic and uncertain environment [32]. This suggests that there will be a large number of information cycles, and it is necessary to manage the information in the process differently. Therefore, the design process in a construction project is more of a communication problem than a technical issue. Management of iterative information flow is one of the most important key characteristics during the design process [33].Figure 2
Design process.The six steps that make up Design Process involve a lot of information exchange as the figure shows. Due to these characteristics of the Design Process in construction engineering, information delivery plays a more important role especially when prefabricated buildings arise as a new type of building.


### 4.2. Delivery Model

The delivery model consists of two modules: requirement delivery and data delivery. Each step of information delivery is complemented by these two modules that are integrated and indispensable.


#### 4.2.1. Requirement Delivery

The IDM standard is the foundation of the information requirement delivery process based on the IFC system; it defines explicitly not only the various phases in the life cycle of a construction project but also the delivery information required by every stakeholder in each phase. IDM maps with public data standard (IFC) to form subsets of BIM models. Then according to information flow and requirements of the project, MVD integrates IDM to standardize the information requirements for a specific phase in the life cycle of the project and provide the requirements to the software vendors.For example, Figure3 shows the information delivery between different software applications. The delivery requirements of software B are determined by the MVD firstly, and then IFC data is extracted through the mappings between MVD and IDM, with results of reducing redundancy in information delivery and increasing delivery efficiency. The whole delivery process is based on delivery requirements, and each information delivery is mapped with the IDM submodel so that the loss of information during the delivery process can be avoided.Figure 3
Information delivery between different software applications.


#### 4.2.2. Data Delivery

Data delivery process is the process of transforming the requirements in the requirement delivery process into data information. As shown in Figure4, the data delivery process based on the IFC schema mainly includes three steps:(1)
Define the IDM standard meticulously on the basis of sufficient research(2)
Map the IFC entities with the IDM standard to form information submodels(3)
Define the MVD according to the requirements of software delivery and generate the information submodelsFigure 4
Data delivery process.


#### 4.2.3. Example of Delivery Model

Taking the architect as an example, Figure5 describes the information delivery process for different stakeholders. Before forming the information model, it has to complete several iterative processes to generate preliminary design, detailed design, and building information model. In each process, after the design review, judgements about whether the design is deliverable will be made, making the design go to the next step or go back to the last step to be revised and reviewed again. After these steps, the information from architects is delivered to corresponding stakeholders (e.g., structural engineers, MEP engineers, and prefabricated component manufacturers). Then there may be some feedback during the process. This is a two-way or iterative delivery process.Figure 5
Information delivery process for architects.


### 4.3. Expansion of the IFC Data Schema for Representing Design Information of the Prefabricated Construction

As the most important exchange standard, IFC is widely adopted in the industry. Although prefabricated buildings play an important role in today’s AEC industry, there is no corresponding support in IFC. In order to achieve the information exchange of prefabricated components better, an expansion method is proposed to representing design information of the prefabricated construction. For the different attributes between prefabricated components and conventional components, this article lists several representative prefabricated component properties, which are added to IFC as extended attributes using the EXPRESS-G language. As shown in Table1, the reserved hole is an important feature of prefabricated components, which will affect the quality of component splicing. Also, the connect method and embedded part are included in the extended properties.Table 1
A property set for IfcPrefabricate construction.
PropertySet name: Pset_PrefabricateConstruction
Applicable entities: IfcWall\Colum\Stair
Name
Data type
Value type
Definition
ReservedHoleArea
IfcAreaMeasure
IfcReal
The area of the Reserved Hole
ReservedHoleShape
IfcPositiveLengthMeasure
IfcReal
The shape of the Reserved Hole
ConnectMethod
IfcConnectionTypeEnum
IfcLabel
The connection type between constructions
EmbeddedPart
IfcEmbedddePartEnum
IfcLabel
Embedded parts reserved in the component
…
…
…EXPRESS-G is a graphical modeling notation developed within STEP and used for IFC definition. In this study, as demonstrated in Figure6, EXPRESS-G was used to identify the data attributes of IFC prefabricate classes and the relationships that exist between classes. IfcWall is used as an example to show the extended attribute information of the prefabricated components. The new attributes in this figure are represented by different colors.Figure 6
EXPRESS-G diagram for Prefabrication Wall Extension.


### 4.4. An Extended IDM Approach for Information Requirements

#### 4.4.1. Developing Process Maps

Since the usage of IDM is to help implement BIM better, which can be achieved only when all involved processes are properly coordinated, a transparent process definition is essential. The process map is one of the three components that make up IDM, the other two exchange requirements (ER) and functional parts (FP). A process map describes the flow of activities within the boundary of a particular topic. The purpose of a process map is to gain an understanding of the configuration of activities that make it work, the actors involved, and the information required, consumed, and produced.A process map has a header section as shown in Table2 to provide administrative information about the process map and identifies the exchange requirements that satisfy the requirements of the process.Table 2
Header section in a process map.
Name
“Cost” model
Identifier
NBS_PM_0001
Change log
Date:∗∗/∗∗/∗∗
Created by∗∗
E-mail:∗∗@∗∗
Exchange requirements
er_exchange_cost_model (order_of_magnitude)
er_exchange_cost_model (preliminary_appraisal)
er_exchange_cost_model (approximate_estimate)
er_exchange_cost_model (preconstruction_estimate)
er_exchange_cost_model (request_for_quotation)
er_exchange_cost_model (quotation)
er_exchange_cost_model (claim_estimate)
er_exchange_cost_model (variation_estimate)
er_exchange_cost_model (final_account)Besides, there is also an overview section to provide a comprehensive discussion of the overall process and specifications of other useful things such as processes, data objects, exchange requirement, and coordination point gateways to provide the necessary information. The tables consist of type, name, and documentation, as shown in Table3.Table 3
Process specification in the process map.
Type
Task
Name
Specify usage profile data
Documentation
Usage profiles are concerned with the time-based usage of spaces and provide information about miscellaneous heat gains/losses to space over time. These include(i) Patterns of people within a space and their activities within the space(ii) Patterns of machinery and equipment usage within the space(iii) Patterns of artificial light usage within the spaceTypically, usage profiles are acquired with space type data. In this process, usage profiles can be added, adapted, and amended for occurrence purposes.Such tables require a description in detail to provide the user with a clear intent and content of every process, data or so on. In this way, users can start to build IDM under a certain standard and make everything traceable.


#### 4.4.2. BPMN Process Map of Architectural Design

Process map diagrams in IDM adopt Business Process Modeling Notation (BPMN). BPMN itself is a specification to create business-specific process diagrams by utilizing a common language and convention. The main parts of the BPMN model include (as illustrated in Figure7):(1)
Swimming pool, which represents the introduced process.(2)
Swimming Lane, a swimming pool can be divided into several swimming lanes (generally distributed by participant activity), which are used for the classification task of diverse functional objectives. Besides, the information model as a separate role owning exclusive lane and exchange requirement as data object is placed on information model lane.(3)
Stream objects including tasks, the basic unit in BPMN, is applied to describe the type of work needed to be done. One task may contain multiple sub-tasks marked by “+”, and other tasks may require repeated process marked by circular symbols, events used to distinguish varying initiating things and results, gateway used to make decisions.(4)
Connecting objects contain sequence stream and message stream.Figure 7
A core subset of BPMN elements.Because of using these elements, a process map was well designed to make sure the communication among users is easy to understand. We adopt the method of BPMN to draw a process map of architecture (including information exchange requirement of other project participants) using the extended algorithm.


#### 4.4.3. Process Map for Prefabricate Construction

In most cases, prefabricated construction is coexisting with the traditional cast-in-place concrete. Planning processes and collaboration are important in this situation. In Figure8, the design process map using BPMN shows the design flow and collaboration among professionals which is an essential part of IDM.Figure 8
Design process map of prefabricated construction.As a new construction method, prefabricated buildings need to cooperate well with other professions. Architecture Design is the leading process as usual. When the Preliminary Design is completed, Design Review will check if the design meets the requirements. The task unit Preliminary Design of Building Architecture is a cyclic task. After the preliminary design plan has passed the review, each major can conduct a preliminary professional design. Due to the nature of the prefabricated building, some of the prefabricated components and piping are closely related to the MEP profession. When structurally splitting a building to form a segmented building component, it is also necessary to fully communicate with the structural profession. Therefore, it is very important to clarify the Exchange Requirement tables between the various professions. Before the Architecture Design Development task, each professional ER table will be integrated into the architectural profession for collaborative deepening design. The next deeper design process is roughly the same as the preliminary design. After review, the final design will be determined. Then other majors can determine their final design based on it.


#### 4.4.4. Exchange Requirement for Prefabricate Construction

Prefabricated components are designed, produced, and constructed in different ways from cast-in-place structures. When engineering data is exchanged with other professions, the prefabrication information normally needs a more sufficient method to be organized and shared. Therefore, ER tables also need to be expanded accordingly. Considering walls, columns, slabs, and stairs are representative and widely used prefabricated components, and the Exchange Requirement definition table proposed in this paper mainly focuses on the four PC components.The exchange requirement definition tables are still classified by profession. Each table mainly consists of the model contents created by the professionals and the model contents required by model receivers at different stages. As shown in Table4, the table firstly covers the BIM model objects to describe “Project” and “Site” in General Information and “walls,” “columns,” “slab,” and “stairs” in Prefabricated information. Each object is a digital representation of the actual building component. Meanwhile, the attribute information attached to the object is added to reflect its physical and functional characteristics. A brief description of the object-attribute information will be presented in “Description” column. An example for such information is a business rule of IDM that adds certain constraints to the attribute values.Table 4
ER table for information requirement in Architecture and Structure design.Because the objects, attributes, and the level of the information details contained in the models which needs to be delivered by each profession at different design stages are different, the information requirements should be defined by model creators. Each exchange requirement is coded by a certain ID number. The code is associated with the flow chart defined previously and can be used to clarify the location of the exchange requirements in the process. An exchange requirement may contain the content of models transmitted by other professions in advance and further supplement model objects of the present profession. For example, in the design stage the information model A_ER.1 and S_ER.1 collected in the preliminary design will be received, and then the required content S_ER.1-A_ER.2 will be extracted to be supplemented in the design model and further form the detailed design model A_ER.2. Therefore, “S_ER.1-A_ER.2” can be filled in the “Prerequisite Requirements” in the definition table to be part of the exchange information. For a set of objects and attributes, there are three options, which are “Require,” “Option,” and “Not required.” “Require” (marked as R and blue color) is for mandatory items. “Option” (marked as O and orange color) is for optional attributes. “Not required” (marked as “-” and grey color) is designed for attributes that are not required. In particular, the depth of detail of some attributes like “Position coordinates” is set according to the requirements in different design stages. So, it can be expressed in terms of “general” and “precise.” On the other hand, although the model is created, different model receivers have their own information requirements. It is still needed to identify the model by codes to build the link with the professional flow charts. The way it is defined is consistent with the definition of model creation requirement, and the required objects and attributes are determined by R, O, or not filled.


## 4.1. Concept Extraction

The Design Process is an approach for breaking down a large project into manageable chunks. Stakeholders such as project managers, discipline engineers, market consultants, and so on use this process to define the steps needed to tackle each project. It consists of six steps: (1) define the problem; (2) collect information; (3) brainstorm and analyze ideas; (4) develop solutions; (5) gather feedback; and (6) improve. As shown in Figure2, each step is interrelated, not isolated. In a construction project, the design process is particularly complex: it involves numerous stakeholders; their requirements must be identified and translated into the process meticulously under a highly dynamic and uncertain environment [32]. This suggests that there will be a large number of information cycles, and it is necessary to manage the information in the process differently. Therefore, the design process in a construction project is more of a communication problem than a technical issue. Management of iterative information flow is one of the most important key characteristics during the design process [33].Figure 2
Design process.The six steps that make up Design Process involve a lot of information exchange as the figure shows. Due to these characteristics of the Design Process in construction engineering, information delivery plays a more important role especially when prefabricated buildings arise as a new type of building.


## 4.2. Delivery Model

The delivery model consists of two modules: requirement delivery and data delivery. Each step of information delivery is complemented by these two modules that are integrated and indispensable.


### 4.2.1. Requirement Delivery

The IDM standard is the foundation of the information requirement delivery process based on the IFC system; it defines explicitly not only the various phases in the life cycle of a construction project but also the delivery information required by every stakeholder in each phase. IDM maps with public data standard (IFC) to form subsets of BIM models. Then according to information flow and requirements of the project, MVD integrates IDM to standardize the information requirements for a specific phase in the life cycle of the project and provide the requirements to the software vendors.For example, Figure3 shows the information delivery between different software applications. The delivery requirements of software B are determined by the MVD firstly, and then IFC data is extracted through the mappings between MVD and IDM, with results of reducing redundancy in information delivery and increasing delivery efficiency. The whole delivery process is based on delivery requirements, and each information delivery is mapped with the IDM submodel so that the loss of information during the delivery process can be avoided.Figure 3
Information delivery between different software applications.


### 4.2.2. Data Delivery

Data delivery process is the process of transforming the requirements in the requirement delivery process into data information. As shown in Figure4, the data delivery process based on the IFC schema mainly includes three steps:(1)
Define the IDM standard meticulously on the basis of sufficient research(2)
Map the IFC entities with the IDM standard to form information submodels(3)
Define the MVD according to the requirements of software delivery and generate the information submodelsFigure 4
Data delivery process.


### 4.2.3. Example of Delivery Model

Taking the architect as an example, Figure5 describes the information delivery process for different stakeholders. Before forming the information model, it has to complete several iterative processes to generate preliminary design, detailed design, and building information model. In each process, after the design review, judgements about whether the design is deliverable will be made, making the design go to the next step or go back to the last step to be revised and reviewed again. After these steps, the information from architects is delivered to corresponding stakeholders (e.g., structural engineers, MEP engineers, and prefabricated component manufacturers). Then there may be some feedback during the process. This is a two-way or iterative delivery process.Figure 5
Information delivery process for architects.


## 4.2.1. Requirement Delivery

The IDM standard is the foundation of the information requirement delivery process based on the IFC system; it defines explicitly not only the various phases in the life cycle of a construction project but also the delivery information required by every stakeholder in each phase. IDM maps with public data standard (IFC) to form subsets of BIM models. Then according to information flow and requirements of the project, MVD integrates IDM to standardize the information requirements for a specific phase in the life cycle of the project and provide the requirements to the software vendors.For example, Figure3 shows the information delivery between different software applications. The delivery requirements of software B are determined by the MVD firstly, and then IFC data is extracted through the mappings between MVD and IDM, with results of reducing redundancy in information delivery and increasing delivery efficiency. The whole delivery process is based on delivery requirements, and each information delivery is mapped with the IDM submodel so that the loss of information during the delivery process can be avoided.Figure 3
Information delivery between different software applications.


## 4.2.2. Data Delivery

Data delivery process is the process of transforming the requirements in the requirement delivery process into data information. As shown in Figure4, the data delivery process based on the IFC schema mainly includes three steps:(1)
Define the IDM standard meticulously on the basis of sufficient research(2)
Map the IFC entities with the IDM standard to form information submodels(3)
Define the MVD according to the requirements of software delivery and generate the information submodelsFigure 4
Data delivery process.


## 4.2.3. Example of Delivery Model

Taking the architect as an example, Figure5 describes the information delivery process for different stakeholders. Before forming the information model, it has to complete several iterative processes to generate preliminary design, detailed design, and building information model. In each process, after the design review, judgements about whether the design is deliverable will be made, making the design go to the next step or go back to the last step to be revised and reviewed again. After these steps, the information from architects is delivered to corresponding stakeholders (e.g., structural engineers, MEP engineers, and prefabricated component manufacturers). Then there may be some feedback during the process. This is a two-way or iterative delivery process.Figure 5
Information delivery process for architects.


## 4.3. Expansion of the IFC Data Schema for Representing Design Information of the Prefabricated Construction

As the most important exchange standard, IFC is widely adopted in the industry. Although prefabricated buildings play an important role in today’s AEC industry, there is no corresponding support in IFC. In order to achieve the information exchange of prefabricated components better, an expansion method is proposed to representing design information of the prefabricated construction. For the different attributes between prefabricated components and conventional components, this article lists several representative prefabricated component properties, which are added to IFC as extended attributes using the EXPRESS-G language. As shown in Table1, the reserved hole is an important feature of prefabricated components, which will affect the quality of component splicing. Also, the connect method and embedded part are included in the extended properties.Table 1
A property set for IfcPrefabricate construction.
PropertySet name: Pset_PrefabricateConstruction
Applicable entities: IfcWall\Colum\Stair
Name
Data type
Value type
Definition
ReservedHoleArea
IfcAreaMeasure
IfcReal
The area of the Reserved Hole
ReservedHoleShape
IfcPositiveLengthMeasure
IfcReal
The shape of the Reserved Hole
ConnectMethod
IfcConnectionTypeEnum
IfcLabel
The connection type between constructions
EmbeddedPart
IfcEmbedddePartEnum
IfcLabel
Embedded parts reserved in the component
…
…
…EXPRESS-G is a graphical modeling notation developed within STEP and used for IFC definition. In this study, as demonstrated in Figure6, EXPRESS-G was used to identify the data attributes of IFC prefabricate classes and the relationships that exist between classes. IfcWall is used as an example to show the extended attribute information of the prefabricated components. The new attributes in this figure are represented by different colors.Figure 6
EXPRESS-G diagram for Prefabrication Wall Extension.


## 4.4. An Extended IDM Approach for Information Requirements

### 4.4.1. Developing Process Maps

Since the usage of IDM is to help implement BIM better, which can be achieved only when all involved processes are properly coordinated, a transparent process definition is essential. The process map is one of the three components that make up IDM, the other two exchange requirements (ER) and functional parts (FP). A process map describes the flow of activities within the boundary of a particular topic. The purpose of a process map is to gain an understanding of the configuration of activities that make it work, the actors involved, and the information required, consumed, and produced.A process map has a header section as shown in Table2 to provide administrative information about the process map and identifies the exchange requirements that satisfy the requirements of the process.Table 2
Header section in a process map.
Name
“Cost” model
Identifier
NBS_PM_0001
Change log
Date:∗∗/∗∗/∗∗
Created by∗∗
E-mail:∗∗@∗∗
Exchange requirements
er_exchange_cost_model (order_of_magnitude)
er_exchange_cost_model (preliminary_appraisal)
er_exchange_cost_model (approximate_estimate)
er_exchange_cost_model (preconstruction_estimate)
er_exchange_cost_model (request_for_quotation)
er_exchange_cost_model (quotation)
er_exchange_cost_model (claim_estimate)
er_exchange_cost_model (variation_estimate)
er_exchange_cost_model (final_account)Besides, there is also an overview section to provide a comprehensive discussion of the overall process and specifications of other useful things such as processes, data objects, exchange requirement, and coordination point gateways to provide the necessary information. The tables consist of type, name, and documentation, as shown in Table3.Table 3
Process specification in the process map.
Type
Task
Name
Specify usage profile data
Documentation
Usage profiles are concerned with the time-based usage of spaces and provide information about miscellaneous heat gains/losses to space over time. These include(i) Patterns of people within a space and their activities within the space(ii) Patterns of machinery and equipment usage within the space(iii) Patterns of artificial light usage within the spaceTypically, usage profiles are acquired with space type data. In this process, usage profiles can be added, adapted, and amended for occurrence purposes.Such tables require a description in detail to provide the user with a clear intent and content of every process, data or so on. In this way, users can start to build IDM under a certain standard and make everything traceable.


### 4.4.2. BPMN Process Map of Architectural Design

Process map diagrams in IDM adopt Business Process Modeling Notation (BPMN). BPMN itself is a specification to create business-specific process diagrams by utilizing a common language and convention. The main parts of the BPMN model include (as illustrated in Figure7):(1)
Swimming pool, which represents the introduced process.(2)
Swimming Lane, a swimming pool can be divided into several swimming lanes (generally distributed by participant activity), which are used for the classification task of diverse functional objectives. Besides, the information model as a separate role owning exclusive lane and exchange requirement as data object is placed on information model lane.(3)
Stream objects including tasks, the basic unit in BPMN, is applied to describe the type of work needed to be done. One task may contain multiple sub-tasks marked by “+”, and other tasks may require repeated process marked by circular symbols, events used to distinguish varying initiating things and results, gateway used to make decisions.(4)
Connecting objects contain sequence stream and message stream.Figure 7
A core subset of BPMN elements.Because of using these elements, a process map was well designed to make sure the communication among users is easy to understand. We adopt the method of BPMN to draw a process map of architecture (including information exchange requirement of other project participants) using the extended algorithm.


### 4.4.3. Process Map for Prefabricate Construction

In most cases, prefabricated construction is coexisting with the traditional cast-in-place concrete. Planning processes and collaboration are important in this situation. In Figure8, the design process map using BPMN shows the design flow and collaboration among professionals which is an essential part of IDM.Figure 8
Design process map of prefabricated construction.As a new construction method, prefabricated buildings need to cooperate well with other professions. Architecture Design is the leading process as usual. When the Preliminary Design is completed, Design Review will check if the design meets the requirements. The task unit Preliminary Design of Building Architecture is a cyclic task. After the preliminary design plan has passed the review, each major can conduct a preliminary professional design. Due to the nature of the prefabricated building, some of the prefabricated components and piping are closely related to the MEP profession. When structurally splitting a building to form a segmented building component, it is also necessary to fully communicate with the structural profession. Therefore, it is very important to clarify the Exchange Requirement tables between the various professions. Before the Architecture Design Development task, each professional ER table will be integrated into the architectural profession for collaborative deepening design. The next deeper design process is roughly the same as the preliminary design. After review, the final design will be determined. Then other majors can determine their final design based on it.


### 4.4.4. Exchange Requirement for Prefabricate Construction

Prefabricated components are designed, produced, and constructed in different ways from cast-in-place structures. When engineering data is exchanged with other professions, the prefabrication information normally needs a more sufficient method to be organized and shared. Therefore, ER tables also need to be expanded accordingly. Considering walls, columns, slabs, and stairs are representative and widely used prefabricated components, and the Exchange Requirement definition table proposed in this paper mainly focuses on the four PC components.The exchange requirement definition tables are still classified by profession. Each table mainly consists of the model contents created by the professionals and the model contents required by model receivers at different stages. As shown in Table4, the table firstly covers the BIM model objects to describe “Project” and “Site” in General Information and “walls,” “columns,” “slab,” and “stairs” in Prefabricated information. Each object is a digital representation of the actual building component. Meanwhile, the attribute information attached to the object is added to reflect its physical and functional characteristics. A brief description of the object-attribute information will be presented in “Description” column. An example for such information is a business rule of IDM that adds certain constraints to the attribute values.Table 4
ER table for information requirement in Architecture and Structure design.Because the objects, attributes, and the level of the information details contained in the models which needs to be delivered by each profession at different design stages are different, the information requirements should be defined by model creators. Each exchange requirement is coded by a certain ID number. The code is associated with the flow chart defined previously and can be used to clarify the location of the exchange requirements in the process. An exchange requirement may contain the content of models transmitted by other professions in advance and further supplement model objects of the present profession. For example, in the design stage the information model A_ER.1 and S_ER.1 collected in the preliminary design will be received, and then the required content S_ER.1-A_ER.2 will be extracted to be supplemented in the design model and further form the detailed design model A_ER.2. Therefore, “S_ER.1-A_ER.2” can be filled in the “Prerequisite Requirements” in the definition table to be part of the exchange information. For a set of objects and attributes, there are three options, which are “Require,” “Option,” and “Not required.” “Require” (marked as R and blue color) is for mandatory items. “Option” (marked as O and orange color) is for optional attributes. “Not required” (marked as “-” and grey color) is designed for attributes that are not required. In particular, the depth of detail of some attributes like “Position coordinates” is set according to the requirements in different design stages. So, it can be expressed in terms of “general” and “precise.” On the other hand, although the model is created, different model receivers have their own information requirements. It is still needed to identify the model by codes to build the link with the professional flow charts. The way it is defined is consistent with the definition of model creation requirement, and the required objects and attributes are determined by R, O, or not filled.


## 4.4.1. Developing Process Maps

Since the usage of IDM is to help implement BIM better, which can be achieved only when all involved processes are properly coordinated, a transparent process definition is essential. The process map is one of the three components that make up IDM, the other two exchange requirements (ER) and functional parts (FP). A process map describes the flow of activities within the boundary of a particular topic. The purpose of a process map is to gain an understanding of the configuration of activities that make it work, the actors involved, and the information required, consumed, and produced.A process map has a header section as shown in Table2 to provide administrative information about the process map and identifies the exchange requirements that satisfy the requirements of the process.Table 2
Header section in a process map.
Name
“Cost” model
Identifier
NBS_PM_0001
Change log
Date:∗∗/∗∗/∗∗
Created by∗∗
E-mail:∗∗@∗∗
Exchange requirements
er_exchange_cost_model (order_of_magnitude)
er_exchange_cost_model (preliminary_appraisal)
er_exchange_cost_model (approximate_estimate)
er_exchange_cost_model (preconstruction_estimate)
er_exchange_cost_model (request_for_quotation)
er_exchange_cost_model (quotation)
er_exchange_cost_model (claim_estimate)
er_exchange_cost_model (variation_estimate)
er_exchange_cost_model (final_account)Besides, there is also an overview section to provide a comprehensive discussion of the overall process and specifications of other useful things such as processes, data objects, exchange requirement, and coordination point gateways to provide the necessary information. The tables consist of type, name, and documentation, as shown in Table3.Table 3
Process specification in the process map.
Type
Task
Name
Specify usage profile data
Documentation
Usage profiles are concerned with the time-based usage of spaces and provide information about miscellaneous heat gains/losses to space over time. These include(i) Patterns of people within a space and their activities within the space(ii) Patterns of machinery and equipment usage within the space(iii) Patterns of artificial light usage within the spaceTypically, usage profiles are acquired with space type data. In this process, usage profiles can be added, adapted, and amended for occurrence purposes.Such tables require a description in detail to provide the user with a clear intent and content of every process, data or so on. In this way, users can start to build IDM under a certain standard and make everything traceable.


## 4.4.2. BPMN Process Map of Architectural Design

Process map diagrams in IDM adopt Business Process Modeling Notation (BPMN). BPMN itself is a specification to create business-specific process diagrams by utilizing a common language and convention. The main parts of the BPMN model include (as illustrated in Figure7):(1)
Swimming pool, which represents the introduced process.(2)
Swimming Lane, a swimming pool can be divided into several swimming lanes (generally distributed by participant activity), which are used for the classification task of diverse functional objectives. Besides, the information model as a separate role owning exclusive lane and exchange requirement as data object is placed on information model lane.(3)
Stream objects including tasks, the basic unit in BPMN, is applied to describe the type of work needed to be done. One task may contain multiple sub-tasks marked by “+”, and other tasks may require repeated process marked by circular symbols, events used to distinguish varying initiating things and results, gateway used to make decisions.(4)
Connecting objects contain sequence stream and message stream.Figure 7
A core subset of BPMN elements.Because of using these elements, a process map was well designed to make sure the communication among users is easy to understand. We adopt the method of BPMN to draw a process map of architecture (including information exchange requirement of other project participants) using the extended algorithm.


## 4.4.3. Process Map for Prefabricate Construction

In most cases, prefabricated construction is coexisting with the traditional cast-in-place concrete. Planning processes and collaboration are important in this situation. In Figure8, the design process map using BPMN shows the design flow and collaboration among professionals which is an essential part of IDM.Figure 8
Design process map of prefabricated construction.As a new construction method, prefabricated buildings need to cooperate well with other professions. Architecture Design is the leading process as usual. When the Preliminary Design is completed, Design Review will check if the design meets the requirements. The task unit Preliminary Design of Building Architecture is a cyclic task. After the preliminary design plan has passed the review, each major can conduct a preliminary professional design. Due to the nature of the prefabricated building, some of the prefabricated components and piping are closely related to the MEP profession. When structurally splitting a building to form a segmented building component, it is also necessary to fully communicate with the structural profession. Therefore, it is very important to clarify the Exchange Requirement tables between the various professions. Before the Architecture Design Development task, each professional ER table will be integrated into the architectural profession for collaborative deepening design. The next deeper design process is roughly the same as the preliminary design. After review, the final design will be determined. Then other majors can determine their final design based on it.


## 4.4.4. Exchange Requirement for Prefabricate Construction

Prefabricated components are designed, produced, and constructed in different ways from cast-in-place structures. When engineering data is exchanged with other professions, the prefabrication information normally needs a more sufficient method to be organized and shared. Therefore, ER tables also need to be expanded accordingly. Considering walls, columns, slabs, and stairs are representative and widely used prefabricated components, and the Exchange Requirement definition table proposed in this paper mainly focuses on the four PC components.The exchange requirement definition tables are still classified by profession. Each table mainly consists of the model contents created by the professionals and the model contents required by model receivers at different stages. As shown in Table4, the table firstly covers the BIM model objects to describe “Project” and “Site” in General Information and “walls,” “columns,” “slab,” and “stairs” in Prefabricated information. Each object is a digital representation of the actual building component. Meanwhile, the attribute information attached to the object is added to reflect its physical and functional characteristics. A brief description of the object-attribute information will be presented in “Description” column. An example for such information is a business rule of IDM that adds certain constraints to the attribute values.Table 4
ER table for information requirement in Architecture and Structure design.Because the objects, attributes, and the level of the information details contained in the models which needs to be delivered by each profession at different design stages are different, the information requirements should be defined by model creators. Each exchange requirement is coded by a certain ID number. The code is associated with the flow chart defined previously and can be used to clarify the location of the exchange requirements in the process. An exchange requirement may contain the content of models transmitted by other professions in advance and further supplement model objects of the present profession. For example, in the design stage the information model A_ER.1 and S_ER.1 collected in the preliminary design will be received, and then the required content S_ER.1-A_ER.2 will be extracted to be supplemented in the design model and further form the detailed design model A_ER.2. Therefore, “S_ER.1-A_ER.2” can be filled in the “Prerequisite Requirements” in the definition table to be part of the exchange information. For a set of objects and attributes, there are three options, which are “Require,” “Option,” and “Not required.” “Require” (marked as R and blue color) is for mandatory items. “Option” (marked as O and orange color) is for optional attributes. “Not required” (marked as “-” and grey color) is designed for attributes that are not required. In particular, the depth of detail of some attributes like “Position coordinates” is set according to the requirements in different design stages. So, it can be expressed in terms of “general” and “precise.” On the other hand, although the model is created, different model receivers have their own information requirements. It is still needed to identify the model by codes to build the link with the professional flow charts. The way it is defined is consistent with the definition of model creation requirement, and the required objects and attributes are determined by R, O, or not filled.


## 5. Integrated Database Construction for the Delivery Process

Data must be managed accurately and effectively to enhance the interoperability. Thus, to facilitate the delivery process, it is necessary to integrate the data developed by the proposed approach into a database so that stakeholders can use it through a user-friendly way.Figure9 illustrates the design of BIM-based data integration of prefabricated construction delivery. BIM data and delivery information requirements are the raw data for the delivery process. Moreover, data is integrated into the database through the extended IFC and IDM for prefabricated construction stated before. Addins are developed to bridge stakeholders and data, making these data accessible for corresponding stakeholders to provide delivery support.Figure 9
Overview of BIM-based data integration of prefabricated construction delivery.To make the data structure simple and flexible, the database adopts the principles of object-oriented programming (OOP), which also coincides with the specialty of prefabricated construction, modularity. As shown in Figure10, inspired by Kang and Choi [34], the BIM-based data integrated database schema structure for prefabricated construction is designed as two parts: the domain schema part (in Figure 10(a)) and the object repository part (in Figure 10(b)). The domain schema categorizes objects and manages their attributes information. The object repository part contains various and exact data sources, from stakeholders to prefabricated components. As the example in Figure 11 shows, the objects of prefabricated buildings are defined simply and flexibly according to the object type and the relationships between them.Figure 10
BIM-based data integrated database schema structure. (a) Domain part. (b) ObjectRepository part.
(a)
(b)Figure 11
Example of BIM-based data integrated database schema structure.


### 5.1. Data Classification for the Delivery Process

Considering that the project delivery process involves complex information sources, the delivery data is divided into different structures for efficient use. As shown in Figure12, graphical delivery data is a kind of unstructured data. Other delivery data include IFC documents and delivery-related documents, which falls under unstructured data as well. While the information delivery manual extended in this study belongs to structured data, it can be expressed via a relational table structure. Therefore, these two kinds of delivery data, structured data and unstructured data, provide quantitative and qualitative perspectives on the delivery information, respectively.Figure 12
Data classification of delivery information.


### 5.2. Data Encoding for the Delivery Process

For convenient data storage and interpretation, a data encoding approach converting delivery information into a specific format is proposed, which covers stakeholders, IFC element, and delivery-related files.


#### 5.2.1. Stakeholders

Stakeholders are encoded by three capital letters. The first one is the initial character of the entity title. For instance, as shown in Table5, STE represents Structure Engineer and ACT represents Architect.Table 5
Encoding of stakeholder.
Stakeholder
Encoding
Architect
ACT
Structural engineer
STE
Mechanical, electrical, and plumbing
MEP
Prefabricated components manufacturer
PCM


#### 5.2.2. IFC Element

In the IFC standard, an IFC object is identified uniquely by IfcGloballyUniqueId which is defined in the entity IfcRoot. So, in this database, a GUID (globally unique identifier), as well as a name and description about the concepts, is used to encode each IFC object. Besides, to recognize different exchange requirement items for different stakeholders in the same IFC object, a six-digit identifier consisting of two parts and a separator is used. Using the codes for stakeholders in Table5, the first part denotes the model creator, the second part denotes the model receiver, and a separator is used to connect them. For example, in Figure 13, “ACT-STE” means the list of exchange items when the model creator is the Architect and the model receiver is the Structural engineer. For the given exchange items, required level which specifies whether they are essential for exchange is needed. In this study, we use “R” and “O” to represent “Requisite” and “Optional” for each exchange item.Figure 13
Encoding example of exchange items (model creator: Architect, model receiver: Structural engineer).


#### 5.2.3. Delivery-Related Files

Codes designed for delivery-related files include two parts. The first part represents the file type and consists of four capital letters, supplemented with the letter “X” if the code has less than four characters. The second part is a six-digit number showing the date. It is designed to distinguish files which have the same format and denote the creation date. These two parts are connected by a separator, as shown in Table6.Table 6
Encoding of delivery-related files.
File type
Encoding
File type
Encoding
PDF
PDFX-190101
JPEG
JPEG-190101
DOC
DOCX-190101
JPG
JPGX-190101
TXT
TXTX-190101
RVT
RVTX-190101
XLSX
XLSX-190101
RFA
RFAX-190101
BMP
BMPX-190101
IFC
IFCX-190101


### 5.3. Design for Conceptual Entity Model for Delivery Database

Considering the data characteristics and actual delivery requirements, entities and attributes are designed as three entities: Stakeholders, IFC elements, and delivery-related files (Table7). The first two are comprised of structured data about construction components and delivery process, while the attributes of the delivery-related files are regarded as unstructured data, which mainly consist of graphical delivery data and other documents.Table 7
Classification of entities and attributes.
Entity
Attribute
Data source
Stakeholder
Reference number
Table5
Name
Real name of specific stakeholders
Contact information
Real contact information of stakeholders
IFC element
Reference number of IFC element
IfcGloabllyUniqueId
Element name
IfcLabel
Detailed description
IfcText
Reference number of exchange requirement items
The encoding
Exchange requirement items
The extended IDM (Information Delivery Manual)
Required level
The extended IDM (Information Delivery Manual), “R” for “Requisite” and “O” for “Optional”
Change log
Records of changes
Delivery-related files
Reference number of files
Table6
File name
File name
Reference number of stakeholders
Table5
Creation date
Time records of file creation
Storage path
Storage path in the systemAfter the entities and attributes are categorized, it is necessary to build the relationship between these entities. The global entity-relationship diagram is shown in Figure14. The entity, attribute, and relationship are represented by the rectangle, ellipse, and diamond box.(1)
The relationship between stakeholder and delivery-related files is defined asn : m, as one stakeholder may require several delivery-related files, and one delivery-files may be viewed by several stakeholders.(2)
The relationship between stakeholder and IFC element is defined asn : m, as one stakeholder requires the delivery information of one IFC element or several IFC elements. One IFC element is also required by one stakeholder or several stakeholders.(3)
The relationship between delivery-related files and IFC element is defined asn : m, as one delivery-related file may contain one IFC element or several IFC elements, one IFC element may also be included in one delivery-related file or several delivery-related files.Figure 14
Entity-relationship diagram for delivery database.


### 5.4. Transforming Conceptual Model to SQL

The last step for constructing the delivery database is to transform the conceptual model to related tables in SQL. As illustrated in Figure13, a hefty part of designing the relational database of the information delivery in prefabricated construction is to divide construction elements/entities into related tables. It is required to rely on relationships between the tables to pull the data together in meaningful ways. As shown in Table 8, the entities and relations designed in Figure 14 were converted into three relational tables (subtables 1–3), which represent the stakeholder, IFC element, and delivery-related files, respectively. For example, stakeholder entities shown in Figure 14 are transformed into a relational model with three attributes listed in the sheet. The same goes for IFC element and delivery-related files.Table 8
Relational tables of the database.
Name
Attribute
Data type
Constraint
Subtable 1: Stakeholder
StakeholderID
Reference number of stakeholders
char(3)
Primary key
StakeholderName
Stakeholder name
varchar(20)
Required
StakeholderCI
Contact information of stakeholders
varchar(50),
Required
Subtable 2: IFC element
ComponentID
Reference number of IFC element
varchar(100)
Composite key
ComponentName
Element name
varchar(20)
Required
ComponentDetail
Detailed description
varchar(20)
Required
ERItemID
Reference number of exchange requirement items
char(7)
Composite key
ERItem
Exchange requirement items
varchar(1000)
Required
RequiredLevel
Required level
char(1)
Required
ChangeLog
Change log
varchar(500)
Required
Subtable 3: Delivery-related files
FileID
Reference number of files
char(11)
Primary key
FileName
File name
varchar(50)
Required
StakeholderID
Reference number of stakeholders
char(3)
Foreign key
CreateTime
Creation date
Date()
Required
StoragePath
Storage path
varchar(40)
Required
Subtable 4: View
FileID
Reference number of files
char(11)
Foreign key
StakeholderID
Reference number of stakeholders
char(3)
Foreign key
Subtable 5: Associate
FileID
Reference number of files
char(11)
Foreign key
ComponentID
Reference number of IFC element
varchar(100)
Foreign key
ERItemID
Reference number of exchange requirement items
char(7)
Foreign key
StakeholderID
Reference number of stakeholders
char(3)
Foreign keyThe database constructs relationships by matching values found in these tables. In these relational tables, there are three kinds of keys to link them, which are primary keys, foreign keys, and composite keys. Primary keys are the unique identifier in each table, while foreign keys track to primary keys in other tables, representing the relationship between these tables. In addition, composite keys use combination of two or more columns in a table to identify each row uniquely. In subtable 2 of Table8, the componentID and ERIemID are used together as composite keys to uniquely identify the IFC element for specific stakeholders. These kinds of keys play a constraint role in these tables. For example, the foreign key of delivery-related files subtable, StakeholderID, references the primary key, StakeholderID, in stakeholder subtable. When inserting or updating data, if users insert a row into delivery-related files subtable whose values of StakeholderID conflict with those of StakeholderID in the existing row in Stakeholder suitable, there will be an error from the database server.As shown in Table9, identifying the mapping relationship between entities is a basic step for the delivery database construction. In these cases, both entities are mandatory, each table corresponds to an entity, and the primary key to an entity can be viewed as the foreign key in other tables. Meanwhile, for the n : m relationship, new tables are needed to establish the association relationship, which are “view,” “associate 1,” and “associate 2.”Table 9
Relationship between two entities.
Each stakeholder requires one or more delivery-related files, and one delivery-related file is viewed by one or more stakeholders.
Each IFC element is required by one or more stakeholders, and one stakeholder requires the information of one or more IFC elements.
Each delivery-related files contain one or more IFC elements, and each IFC element is included in one or more delivery-related files.
Create table Stakeholder (StakeholderID char(3),
StakeholderName varchar(20),
StakeholderCI varchar(50),
Primary key (StakeholderID);
Create table Delivery-related files (FileID char(11),
FileName varchar(50),
StakeholderID char(3),
CreateTime date(),
StoragePath varchar(40),
Primary key (FileID);
Create table view (FileID char(11),
StakeholderID char(3),
Primary key (FileID, StakeholderID);
Foreign key (FileID) references delivery-related files on delete set default on update cascade),
Foreign key (StakeholderID) references stakeholders (StakeholderID));
Create table Stakeholder (StakeholderID char(3),
StakeholderName varchar(20),
StakeholderCI varchar(50),
Primary key (StakeholderID);
Create table IFC element (ComponentID varchar(100),
ComponentName varchar(20),
ComponentDetail varchar(20),
ERItemID char(7),
ERItem varchar(1000),
RequiredLevel char(1),
ChangeLog varchar(500),
Primary key (ComponentID);
Create table associate1 (ComponentID varchar(100),
ERItemID char(7),
StakeholderID char(3),
Primary key (ComponentID, ERItemID, StakeholderID),
Foreign key (ComponentID, ERItemID) references IFC element on delete set default on update cascade),
Foreign key (StakeholderID) references stakeholders (StakeholderID));
Create table Delivery-related files (FileID char(11),
FileName varchar(50),
StakeholderID char(3),
CreateTime date(),
StoragePath varchar(40),
Primary key (FileID);
Create table IFC element (ComponentID varchar(100),
ComponentName varchar(20),
ComponentDetail varchar(20),
ERItemID char(7),
ERItem varchar(1000),
RequiredLevel char(1),
ChangeLog varchar(500),
Primary key (ComponentID);
Create table associate2 (ComponentID varchar(100),
ERItemID char(7),
FileID char(11),
Primary key (ComponentID, ERItemID, FileID),
Foreign key (ComponentID, ERItemID) references IFC element on delete set default on update cascade),
Foreign key (FileID) references delivery-related files (FileID));


## 5.1. Data Classification for the Delivery Process

Considering that the project delivery process involves complex information sources, the delivery data is divided into different structures for efficient use. As shown in Figure12, graphical delivery data is a kind of unstructured data. Other delivery data include IFC documents and delivery-related documents, which falls under unstructured data as well. While the information delivery manual extended in this study belongs to structured data, it can be expressed via a relational table structure. Therefore, these two kinds of delivery data, structured data and unstructured data, provide quantitative and qualitative perspectives on the delivery information, respectively.Figure 12
Data classification of delivery information.


## 5.2. Data Encoding for the Delivery Process

For convenient data storage and interpretation, a data encoding approach converting delivery information into a specific format is proposed, which covers stakeholders, IFC element, and delivery-related files.


### 5.2.1. Stakeholders

Stakeholders are encoded by three capital letters. The first one is the initial character of the entity title. For instance, as shown in Table5, STE represents Structure Engineer and ACT represents Architect.Table 5
Encoding of stakeholder.
Stakeholder
Encoding
Architect
ACT
Structural engineer
STE
Mechanical, electrical, and plumbing
MEP
Prefabricated components manufacturer
PCM


### 5.2.2. IFC Element

In the IFC standard, an IFC object is identified uniquely by IfcGloballyUniqueId which is defined in the entity IfcRoot. So, in this database, a GUID (globally unique identifier), as well as a name and description about the concepts, is used to encode each IFC object. Besides, to recognize different exchange requirement items for different stakeholders in the same IFC object, a six-digit identifier consisting of two parts and a separator is used. Using the codes for stakeholders in Table5, the first part denotes the model creator, the second part denotes the model receiver, and a separator is used to connect them. For example, in Figure 13, “ACT-STE” means the list of exchange items when the model creator is the Architect and the model receiver is the Structural engineer. For the given exchange items, required level which specifies whether they are essential for exchange is needed. In this study, we use “R” and “O” to represent “Requisite” and “Optional” for each exchange item.Figure 13
Encoding example of exchange items (model creator: Architect, model receiver: Structural engineer).


### 5.2.3. Delivery-Related Files

Codes designed for delivery-related files include two parts. The first part represents the file type and consists of four capital letters, supplemented with the letter “X” if the code has less than four characters. The second part is a six-digit number showing the date. It is designed to distinguish files which have the same format and denote the creation date. These two parts are connected by a separator, as shown in Table6.Table 6
Encoding of delivery-related files.
File type
Encoding
File type
Encoding
PDF
PDFX-190101
JPEG
JPEG-190101
DOC
DOCX-190101
JPG
JPGX-190101
TXT
TXTX-190101
RVT
RVTX-190101
XLSX
XLSX-190101
RFA
RFAX-190101
BMP
BMPX-190101
IFC
IFCX-190101


## 5.2.1. Stakeholders

Stakeholders are encoded by three capital letters. The first one is the initial character of the entity title. For instance, as shown in Table5, STE represents Structure Engineer and ACT represents Architect.Table 5
Encoding of stakeholder.
Stakeholder
Encoding
Architect
ACT
Structural engineer
STE
Mechanical, electrical, and plumbing
MEP
Prefabricated components manufacturer
PCM


## 5.2.2. IFC Element

In the IFC standard, an IFC object is identified uniquely by IfcGloballyUniqueId which is defined in the entity IfcRoot. So, in this database, a GUID (globally unique identifier), as well as a name and description about the concepts, is used to encode each IFC object. Besides, to recognize different exchange requirement items for different stakeholders in the same IFC object, a six-digit identifier consisting of two parts and a separator is used. Using the codes for stakeholders in Table5, the first part denotes the model creator, the second part denotes the model receiver, and a separator is used to connect them. For example, in Figure 13, “ACT-STE” means the list of exchange items when the model creator is the Architect and the model receiver is the Structural engineer. For the given exchange items, required level which specifies whether they are essential for exchange is needed. In this study, we use “R” and “O” to represent “Requisite” and “Optional” for each exchange item.Figure 13
Encoding example of exchange items (model creator: Architect, model receiver: Structural engineer).


## 5.2.3. Delivery-Related Files

Codes designed for delivery-related files include two parts. The first part represents the file type and consists of four capital letters, supplemented with the letter “X” if the code has less than four characters. The second part is a six-digit number showing the date. It is designed to distinguish files which have the same format and denote the creation date. These two parts are connected by a separator, as shown in Table6.Table 6
Encoding of delivery-related files.
File type
Encoding
File type
Encoding
PDF
PDFX-190101
JPEG
JPEG-190101
DOC
DOCX-190101
JPG
JPGX-190101
TXT
TXTX-190101
RVT
RVTX-190101
XLSX
XLSX-190101
RFA
RFAX-190101
BMP
BMPX-190101
IFC
IFCX-190101


## 5.3. Design for Conceptual Entity Model for Delivery Database

Considering the data characteristics and actual delivery requirements, entities and attributes are designed as three entities: Stakeholders, IFC elements, and delivery-related files (Table7). The first two are comprised of structured data about construction components and delivery process, while the attributes of the delivery-related files are regarded as unstructured data, which mainly consist of graphical delivery data and other documents.Table 7
Classification of entities and attributes.
Entity
Attribute
Data source
Stakeholder
Reference number
Table5
Name
Real name of specific stakeholders
Contact information
Real contact information of stakeholders
IFC element
Reference number of IFC element
IfcGloabllyUniqueId
Element name
IfcLabel
Detailed description
IfcText
Reference number of exchange requirement items
The encoding
Exchange requirement items
The extended IDM (Information Delivery Manual)
Required level
The extended IDM (Information Delivery Manual), “R” for “Requisite” and “O” for “Optional”
Change log
Records of changes
Delivery-related files
Reference number of files
Table6
File name
File name
Reference number of stakeholders
Table5
Creation date
Time records of file creation
Storage path
Storage path in the systemAfter the entities and attributes are categorized, it is necessary to build the relationship between these entities. The global entity-relationship diagram is shown in Figure14. The entity, attribute, and relationship are represented by the rectangle, ellipse, and diamond box.(1)
The relationship between stakeholder and delivery-related files is defined asn : m, as one stakeholder may require several delivery-related files, and one delivery-files may be viewed by several stakeholders.(2)
The relationship between stakeholder and IFC element is defined asn : m, as one stakeholder requires the delivery information of one IFC element or several IFC elements. One IFC element is also required by one stakeholder or several stakeholders.(3)
The relationship between delivery-related files and IFC element is defined asn : m, as one delivery-related file may contain one IFC element or several IFC elements, one IFC element may also be included in one delivery-related file or several delivery-related files.Figure 14
Entity-relationship diagram for delivery database.


## 5.4. Transforming Conceptual Model to SQL

The last step for constructing the delivery database is to transform the conceptual model to related tables in SQL. As illustrated in Figure13, a hefty part of designing the relational database of the information delivery in prefabricated construction is to divide construction elements/entities into related tables. It is required to rely on relationships between the tables to pull the data together in meaningful ways. As shown in Table 8, the entities and relations designed in Figure 14 were converted into three relational tables (subtables 1–3), which represent the stakeholder, IFC element, and delivery-related files, respectively. For example, stakeholder entities shown in Figure 14 are transformed into a relational model with three attributes listed in the sheet. The same goes for IFC element and delivery-related files.Table 8
Relational tables of the database.
Name
Attribute
Data type
Constraint
Subtable 1: Stakeholder
StakeholderID
Reference number of stakeholders
char(3)
Primary key
StakeholderName
Stakeholder name
varchar(20)
Required
StakeholderCI
Contact information of stakeholders
varchar(50),
Required
Subtable 2: IFC element
ComponentID
Reference number of IFC element
varchar(100)
Composite key
ComponentName
Element name
varchar(20)
Required
ComponentDetail
Detailed description
varchar(20)
Required
ERItemID
Reference number of exchange requirement items
char(7)
Composite key
ERItem
Exchange requirement items
varchar(1000)
Required
RequiredLevel
Required level
char(1)
Required
ChangeLog
Change log
varchar(500)
Required
Subtable 3: Delivery-related files
FileID
Reference number of files
char(11)
Primary key
FileName
File name
varchar(50)
Required
StakeholderID
Reference number of stakeholders
char(3)
Foreign key
CreateTime
Creation date
Date()
Required
StoragePath
Storage path
varchar(40)
Required
Subtable 4: View
FileID
Reference number of files
char(11)
Foreign key
StakeholderID
Reference number of stakeholders
char(3)
Foreign key
Subtable 5: Associate
FileID
Reference number of files
char(11)
Foreign key
ComponentID
Reference number of IFC element
varchar(100)
Foreign key
ERItemID
Reference number of exchange requirement items
char(7)
Foreign key
StakeholderID
Reference number of stakeholders
char(3)
Foreign keyThe database constructs relationships by matching values found in these tables. In these relational tables, there are three kinds of keys to link them, which are primary keys, foreign keys, and composite keys. Primary keys are the unique identifier in each table, while foreign keys track to primary keys in other tables, representing the relationship between these tables. In addition, composite keys use combination of two or more columns in a table to identify each row uniquely. In subtable 2 of Table8, the componentID and ERIemID are used together as composite keys to uniquely identify the IFC element for specific stakeholders. These kinds of keys play a constraint role in these tables. For example, the foreign key of delivery-related files subtable, StakeholderID, references the primary key, StakeholderID, in stakeholder subtable. When inserting or updating data, if users insert a row into delivery-related files subtable whose values of StakeholderID conflict with those of StakeholderID in the existing row in Stakeholder suitable, there will be an error from the database server.As shown in Table9, identifying the mapping relationship between entities is a basic step for the delivery database construction. In these cases, both entities are mandatory, each table corresponds to an entity, and the primary key to an entity can be viewed as the foreign key in other tables. Meanwhile, for the n : m relationship, new tables are needed to establish the association relationship, which are “view,” “associate 1,” and “associate 2.”Table 9
Relationship between two entities.
Each stakeholder requires one or more delivery-related files, and one delivery-related file is viewed by one or more stakeholders.
Each IFC element is required by one or more stakeholders, and one stakeholder requires the information of one or more IFC elements.
Each delivery-related files contain one or more IFC elements, and each IFC element is included in one or more delivery-related files.
Create table Stakeholder (StakeholderID char(3),
StakeholderName varchar(20),
StakeholderCI varchar(50),
Primary key (StakeholderID);
Create table Delivery-related files (FileID char(11),
FileName varchar(50),
StakeholderID char(3),
CreateTime date(),
StoragePath varchar(40),
Primary key (FileID);
Create table view (FileID char(11),
StakeholderID char(3),
Primary key (FileID, StakeholderID);
Foreign key (FileID) references delivery-related files on delete set default on update cascade),
Foreign key (StakeholderID) references stakeholders (StakeholderID));
Create table Stakeholder (StakeholderID char(3),
StakeholderName varchar(20),
StakeholderCI varchar(50),
Primary key (StakeholderID);
Create table IFC element (ComponentID varchar(100),
ComponentName varchar(20),
ComponentDetail varchar(20),
ERItemID char(7),
ERItem varchar(1000),
RequiredLevel char(1),
ChangeLog varchar(500),
Primary key (ComponentID);
Create table associate1 (ComponentID varchar(100),
ERItemID char(7),
StakeholderID char(3),
Primary key (ComponentID, ERItemID, StakeholderID),
Foreign key (ComponentID, ERItemID) references IFC element on delete set default on update cascade),
Foreign key (StakeholderID) references stakeholders (StakeholderID));
Create table Delivery-related files (FileID char(11),
FileName varchar(50),
StakeholderID char(3),
CreateTime date(),
StoragePath varchar(40),
Primary key (FileID);
Create table IFC element (ComponentID varchar(100),
ComponentName varchar(20),
ComponentDetail varchar(20),
ERItemID char(7),
ERItem varchar(1000),
RequiredLevel char(1),
ChangeLog varchar(500),
Primary key (ComponentID);
Create table associate2 (ComponentID varchar(100),
ERItemID char(7),
FileID char(11),
Primary key (ComponentID, ERItemID, FileID),
Foreign key (ComponentID, ERItemID) references IFC element on delete set default on update cascade),
Foreign key (FileID) references delivery-related files (FileID));


## 6. Discussion

The purpose of this study is to extend the IDM for prefabricated buildings so that the information requirements can be recognized, documented, and referenced by different stakeholders during the delivery process of the prefabricated building. Thus, the proposed approach should be implemented considering the practical interaction between the proposed IDM and corresponding stakeholders. In this study, a webserver and User-Interface (UI) is applied to illustrate the implementation process partly. Figure15 shows an overview of the system design. The webserver stores the IDM into a relational database, and the UI provides a friendly way for users to manage data in the webserver and export the exchange requirements required by different stakeholders. As shown in Figure 16, first, according to the stakeholders involved in different information exchange processes, the operator selects the corresponding model creator and model receiver. Then the exchange requirements are exported from the webserver in EXCEL format by clicking the “Generate” button. Finally, the exchange requirements can be viewed by different stakeholders explicitly. Hereby, it can facilitate the information sharing between stakeholders from different disciplines by using the proposed approach automatically and completely in the delivery process for prefabricated buildings.Figure 15
Overview of system design.Figure 16
Implementation process.Here a project shown in Figure17 is selected as an example. This is a prefabricated reinforced concrete frame building which includes prefabricated beams, columns, slabs, and stairs. The information delivery manual was defined in the database firstly. Then, as shown in Figure 18, to get the exchange requirement of architecture, the architect was set as the model creator, the structural engineer and MEP engineer were set as the model receivers. Next, the file was exported and viewed, as shown in Figure 19. From the ER table we exported, we can know the explicit information about the exchange requirements of the project during the delivery process. Using this platform, the structure engineers and MEP engineers can know what the requirements are straightforwardly and easily when the model is delivered by the architects. On the other hand, the architects can also know the exchange requirements when they deliver models to others very clearly. As we can see, this method automatically generates exchange requirements between the model creator and model receiver, which helps to make the information exchange process more efficient and clearer.Figure 17
A sample case of prefabricated reinforced concrete frame building.Figure 18
Select involved professionals.Figure 19
Exchange requirement for architecture of the sample project.In prefabricated construction, the components have many other different properties (connected method, embedded parts, etc.) which make the exchange requirements quite different from those of cast-in-place components. This extended IDM approach has made the delivery information in prefabricated construction more specific and accurate for different stakeholders. On the other hand, the design of prefabricated buildings is a highly industrialized process, different professions should collaborate with each other closely, which means that the communication matters a lot during the delivery process. With this integrated database, the management of the project delivery information is believed to be systematical and automated, which will significantly reduce the cost of communication between the various disciplines, as well as the repetitive work due to poor coordination.


## 7. Limitations and Future Work

Three main limitations of this work are acknowledged for further development and broader application. First, although the information requirements of stakeholders, such as architecture designer, structure designer, MEP designer, and PC Manufacturer, are defined as complete as possible, this research mainly focuses on the early stage of the prefabricated construction. Further research is needed to study the information requirements in the other stages, such as construction and maintenance stage, to facilitate the delivery process through a globally available IDM server for the AEC industry from a life-cycle perspective. Second, the platform developed in this research needs to be more automatic and intelligent. For example, for different projects, each one needs human involvements to define the delivery manual. If enough cases and data are collected in the future, ontology-based algorithms could be developed to automatically identify and define the information requirements in different projects. Third, due to the limitation of resources, this research only applies the IDM-based database to one practical project for testing its effectiveness. The performance should be evaluated further through more practical projects in the future studies.Besides, in future applications, the cost of adopting the proposed method and platform should be considered carefully. The workload of developing and maintaining a database system for IDM requirements is relatively heavy, especially for big and complex projects. It would be beneficial to develop a machine-readable standard for exchanging IDM information, similar to MVD/mvdXML, to reduce the cost of storage and maintenance of it.In comparison to existing efforts in the construction domain, this work contributes to the body of knowledge in two main ways. First, in order to make up for the vacancy of prefabricated components management and information delivery in prefabricated construction, this paper uses the existing IDM framework, combined with prefabricated buildings and other multidisciplines, to extend the framework and provide standards for information delivery of fabricated buildings. In order to meet the needs of the use of the IDM framework, this paper also proposes the expansion of the prefabricated construction part in IFC standard and improves the IDM structure. At the same time, this article has carried out detailed operations in specific cases, providing a template for subsequent use. Second, this paper lays the foundation for the practical engineering application of information delivery for prefabricated construction by designing the database. Through the analysis of IFC, IDM, stakeholders, and the design of the coding system, the database structure is verified and demonstrated in practice.


## 8. Conclusion

Stakeholders in prefabricated construction have difficulty in specifying BIM objects’ data to be delivered automatically in the workflow, which requires an in-depth understanding of the construction content requirements (attributes) and BIM uses (i.e., Structure design). Currently, establishing information delivery requirements so that they inform not only the physical product being delivered, but also its digital representation containing related project information is a significant challenge [35]. The IDM can be applied to establish the professional knowledge basis of the domain of prefabricated construction in order to ensure the information delivery of the technical components in the system. It specifies the data collection process; details the activities for 3D model reconstruction and the geometric shape representations needed; presents the process of semantic enrichment and the required structured knowledge [16]. This paper has contributed to extending the IFC schema to handle the prefabricated construction requirements. The extension is based on literature review and practical experience. As various researchers have reported the current error-prone process of developing IDM due to the difficulties in reusing and tracking exchange and functional requirements, a database management system and a user-interface have been introduced to provide a systematical way for managing exchange requirements and generating IDM for a particular model builder and receiver. Accordingly, the coordination and collaboration among the project participants are improved, which assist in making decisions.Despite the various benefits, the limitations of the developed IDM-based database for prefabricated construction in the research should be also outlined for its further development and broader application. Due to the limitations of resource, this research only applies the IDM-based database to only one practical project for testing its effectiveness. Besides, this research focuses more on the information requirements of the stakeholders, e.g., architecture design, structure design, MEP design, and PC Manufacturer in the early stage of the prefabricated construction, while stakeholders’ requirements in the stage of construction and maintenance are also important for prefabricated construction project. As a next step, it is crucial to investigate the development of a globally available IDM server for the AEC industry. Such a server would provide a platform for practitioners to agree on and reuse exchange requirements in a machine-readable manner. Additionally, although in this paper we have proposed managing IDM requirements in a database management system, developing a machine-readable standard for exchanging IDM information, similar to MVD/mvdXML, would be beneficial.



---

*Source: 8946530-2020-01-27.xml*