BIM and Ontology-Based DfMA Framework for Prefabricated Component

Abstract

The integration of Design for Manufacture and Assembly (DfMA) into the design process of industrialized construction has the potential to reduce errors and changes occurring after the design has been finalized, ultimately improving overall productivity. Based on DfMA, the designers would need to consider whether their designs meet the architectural and performance requirements, as well as the manufacturing and assembly requirements from assembly and manufacturing technicians. However, some limitations present challenges for DfMA-oriented prefabricated design, such as lack of information interoperability, lack of conflict detection and management, and inefficient data processing and requirement checking. Thus, this research presents a novel BIM and ontology-based framework for DfMA of prefabricated and modular components. Various types of algorithms, plugins, and programming are also integrated to support the operation of the framework. The primary functions of this framework include: (1) collection of various stakeholder requirements in a standardized data format; (2) conflict detection and resolution between the design, manufacturing, and assembly requirements; and (3) automated compliance checking of whether the designed BIM models meet DfMA requirements. This research applies the framework on a prefabricated hotel project as a case study to validate the feasibility of the framework. Based on the results of a user experience survey, the developed framework shows promise for improving the DfMA process and stakeholder communication. Although a few limitations were encountered, such as the low computer operating speed and the limited ontology, the framework has been validated and shows great potential in advancing prefabricated component design applications

1. Introduction

1.1. Background

The construction industry is often criticized for its low productivity, high greenhouse emissions, and high waste generation compared to other industries. There has been a new shift within the construction industry to implement intelligent manufacturing and automation techniques to improve traditional construction processes, which is referred to as industrialized construction [1]. Industrialized construction has advantages over traditional construction in improved quality, reduced construction cost, reduced construction time, reduced labor, and improved sustainability [2,3,4]. Prefabrication, as one of the main technologies in industrialized construction, is defined as the process of producing prefabricated systems, building components, or building structures in a protected factory environment and transporting them to the construction site for installation or assembly [5,6,7].

The early design decisions are important to the projects since they determine the majority of the economic and environmental impacts of the buildings [8]. However, the current design methods of buildings for industrialized construction are largely based on the traditional design methods used, which causes issues further down the life cycle of the building. Traditional design methods only require the designers to consider the architectural, structural, and customer requirements, without the considerations of the manufacturing, transportation, and assembly requirements [9]. Factory regulations, production constraints, and construction constraints can impose requirements on the design of the prefabricated components [10]. Insisting on applying a traditional design system in industrialized construction will cause increased design alterations and decreased design efficiency.

The integration of Design for Manufacture and Assembly (DfMA) into the design process of industrialized construction has been shown to help designers optimize prefabricated building design [11,12]. Under the concept of DfMA, designers should consider the requirements of both manufacturing and assembly of industrialized buildings. For a DfMA-oriented design approach, various teams such as designers, engineers, contractors, and manufacturers should work together to finalize the design [8].

Currently, DfMA-oriented prefabricated design research is still in its initial stage and has many limitations, such as lack of information interoperability, lack of working and communication efficiency, and lack of conflict management. Therefore, this research addresses these issues by introducing ontology, automated requirement checking, and conflict detection techniques into DfMA. Specifically, this paper focuses on the development and validation of Building Information Modeling (BIM) and an ontology-based DfMA framework for prefabricated design. The primary functions of this framework include: (1) collection of various project team’s requirements in a common and open data format; (2) conflict detection and resolution between the design requirements and the manufacturing and assembly requirements; and (3) automatic checking on whether the designed components BIM models meet the design, manufacturing, and assembly requirements. Significantly, the developed framework shows promise of improving the DfMA process and stakeholder communication according to the results of a user-experience survey on the framework.

1.2. Overview of Prefabrication, DfMA, and Ontologies

1.2.1. Prefabrication

Prefabrication indicates the practice of producing the components of a structure in a factory and transporting complete or semi-complete assemblies to the construction site where the structure is to be located [5,6,7]. The degree of prefabrication in an industrialized project can be categorized into four levels: (1) individually manufactured; (2) elements or two-dimensional systems; (3) modular and complete sections; and (4) complete building systems [13]. The component with a high prefabrication level is composed of components with a low prefabrication level.

1.2.2. Design for Manufacture and Assembly (DfMA)

DfMA is a mature engineering methodology with two parts: Design for Manufacturing (DfM) and Design for Assembling (DfA). As defined by Constance [14], DfM is “the design for ease of manufacture of the collection of the parts that will form the product”, while DfA is “the design of the product for ease of assembly”. Together, DfMA, enables product designers to consider available material selection, cost, manufacturability, and assemblability to determine the most efficient design. Designing with these considerations has been shown to reduce time, cost, and labor while increasing quality and efficiency in the manufacturing industry. Even though different research from different areas has defined various DfMA flows or steps, they share substantial similarities in DfMA principles.

1.2.3. DfMA in Construction

Current research on practical DfMA-oriented prefabricated design for the construction industry is limited. The majority of the research either focuses on discussing the future potential of DfMA implementation in industrialized construction (e.g., [12]) or proposes a theoretical DfMA-oriented parameter design approach (e.g., [7,11]). Specifically, Chen et al. [11] suggested that the DfMA-oriented design process should start with forming a multidisciplinary team consisting of designers, engineers, manufacturers, and contractors. The manufacturers and contractors should meet with designers and engineers through regular meetings to finalize the designs. However, Chen et al. [11] also mentioned that forming an operative multidisciplinary team is quite challenging. It is necessary to evaluate whether the benefits of forming such a multidisciplinary team could be offset by the resulting management costs. Another major limitation mentioned in Chen et al. [11] is that an advanced and digital platform is needed to reduce the manual work on updating the design documents.

In addition, Wasim et al. [12] discussed how DfMA could be implemented in industrialized construction. They created a catalogue of products and associated data to evaluate the production time, cost, and quality. However, this information is difficult to accurately obtain in the construction industry [14]. The implementation of DfMA in industrialized construction is negatively affected by the lack of access to necessary information. By comparison, Gerth et al. [15] suggested that when applying DfMA in construction, the design performance should be evaluated by investigating whether the predefined criteria are met.

Yuan et al. [8] proposed a comprehensive DfMA-oriented prefabricated information model optimization framework (Figure 1). In their framework, architectural designers work with split designers and structural designers to complete the initial prefabricated building information model through a BIM platform. Among them, architectural designers focus on the appearance design of the building; structural designers focus on the strength and durability analysis of the building; split designers are responsible for determining which components of a building should be prefabricated. After that, the initial prefabricated building information model is handed to manufacturers and contractors to implement the manufacture and construction simulations. If some questions are found in the simulation process, the information will be fed back to the BIM models, and thus the designers can optimize it. However, their research was still at the theoretical stage without real-world validation.

Table 1. Previous research on DfMA in industrialized construction.

Research	Component Type	Parameters
[12]	Curtain wall	Manufacturing technology, length, width, fire rating, corrosion resistance, unit price, service life.
[10]	Timber slab	Length, width, height, thickness, fire rating, unit price, connection type, nail type.
[16]	Concrete slab/concrete wall	Weight, rigidity, length.
[17]	Concrete wall/brick wall	Connection type, finish type, material type, geometric, weight, equipment type, fragility, number of workers, cost.

lists research that covers specific component types, including the configurations of various parameters and attributes. However, a comprehensive and practical DfMA prefabricated design framework for construction is lacking.

1.2.4. Interoperability and Ontologies

Interoperability is a major aspect of the DfMA process in construction since each stakeholder of the project team has individual data requirements that often require different software systems. Various types of methods have been adopted to ensure the information interoperability between isolated sub-systems and software. Pauwels et al. [18] classified the methods for interoperability into four major categories. Specifically:

• Translators, middleware, and mapping. This category represents the use of a middle solution that transfers the data from the sending format to the receiving format. Specifically, the translator translates the data from a different format to a format compatible with the application level (e.g., BIM authoring tool); middleware is an external software that can be applied between components on the network level (e.g., Internet protocols); and mapping connects one source to another on the data level.
• Open application programming interfaces. Application programming interfaces (APIs) enable the direct application-to-application information sharing by having subroutine definitions and variables, protocols, and tools.
• Information exchange. Information exchange represents the application of a domain-approved standard for the data representation, definitions, rules, and requirements, which is designed to ensure the reliable and automatic exchange between heterogeneous software. Industry foundation classes (IFCs) are the most common neutral file format for data exchanges in the AECO industry. However, the application of IFCs to solving interoperability in AECO is prevented for several reasons: 1) IFC is complex and has great redundancies. The redundant data representations can create problems such as mismatching and inconsistencies; and 2) developing an interdisciplinary exchange standard requires an additional level of significant coordination between domains [18]. Current IFCs are mainly developed for building design, without sufficient attributes about manufacturing and assembly.
• Ontologies and semantic web. Ontology defines standardized and machine-readable definitions and concepts in specific domains. The semantic web is a collection of web-based technologies and protocols based on worldwide web consortium (W3C) standards.

Since each method has its own features and scalability, each of them has its benefits depending on the application. Among these, the use of ontology has been proclaimed by many researchers [18] to be the most promising method to enable interoperability across different interdisciplinary domains.

1.2.5. Ontology Model and Languages

An ontological model is composed of three major components: classes, instances, and properties [19,20].

• Among them, classes are a core component of the ontology. A class represents a group of different individuals that share common characteristics.
• Instances, or individuals, are the basic units of the ontology. The individuals in an ontology may include concrete objects such as people and animals, as well as abstract individuals such as numbers.
• Properties are relations that link one individual to another. There are two main types of properties: object and data type. An object property is a relationship between two individuals. Datatype properties link instances to data values.

There are different serializations that code and describe ontologies in a machine-readable form, such as Extensible Markup Language (XML), XMLS (Extensible Markup Language Schema), Resource Description Framework (RDF), RDFS (RDF Schema), and Web Ontology Language (OWL) [21]. Specifically:

• XML is one of the early ontology languages. It provides a surface syntax for structured documents but imposes no semantic constraints on the meaning of the documents.
• XMLS is a language for restricting the structure of XML documents and also extends XML with datatypes.
• RDF is a framework for conceptual description and modeling information implemented in web resources. RDF is composed of three components, known as RDF triples: subject, predicate, and object. RDF triples state a single fact about a resource in which the subject is the subject being described, the predicate is the relationship of the subject, and the object represents what is related to the subject by the predicate [22].
• RDFS is a vocabulary for describing properties and classes of RDF resources.
• OWL is built based on RDF. OWL is compatible with RDF schema and can augment the meaning of existing RDF vocabulary. Compared to other languages, OWL is more comprehensive and adds more vocabulary for describing properties and classes.

There is a wide range of literature focusing on adopting ontology in the construction industry to support different functions such as optimized conceptual design of prefabricated facades [23], quantity take-off [24], and defect management [25]. However, the applications of ontology in industrialized construction, namely one that is specific to prefabricated components, has not been developed yet [1].

1.3. Research Gaps

By summarizing the limitations existing in current research of DfMA-oriented design (as seen in Section 1.2.3), this research identified the following four gaps:

• Gap 1: Lack of a comprehensive DfMA-oriented prefabricated design framework

Currently, a comprehensive and feasible DfMA platform for industrialized construction has not been developed. The existing attempts of introducing DfMA into prefabricated design are still at the theoretical stage without solid validation. Some other existing research focused solely on a certain prefabricated component. Without a feasible and comprehensive framework, industrialized construction will still experience inefficiencies, changes, and rework. To address this gap, this research aims to develop and validate a comprehensive and integrated DfMA platform for industrialized construction.

• Gap 2: Lack of information interoperability among the stakeholders

Existing research ignores the importance of information interoperability for a DfMA-oriented prefabricated design. In industrialized construction, information is heterogeneous and is represented in different data formats or described in different terms in different stakeholder’s applications or documents [19]. Such a lack of data interoperability would cause errors, omissions, or data loss when information is transferred. For example, in the feedback that manufacturers and contractors send to the designers, they could describe the same object with different terms compared to those in the designers’ models. Designers have to confirm the meaning of the terms with manufacturers and contractors; otherwise, it will cause inaccuracy of requirement-checking results. This research introduces an ontology model to assist in improving the information interoperability in DfMA-oriented prefabricated design.

• Gap 3: Lack of efficient conflict management in DfMA

Conflict resolution, such as clash detection, has been a game changer in using BIM for the design process of typical buildings. However, the existing research has not developed efficient methods to manage the potential conflicts in DfMA-oriented prefabricated design process. Designers are heavily influenced by established design codes in the creation of their models. Manufactures are limited by production capabilities, such as standard dimensions and machinery. Contractors and builders are driven by schedule and costs, which limits the materials they can purchase. Without efficient conflict detection and resolution mechanism, the constraints from the manufacturers and contractors could conflict with the existing design codes, which can cause design iterations. To address this gap, this research develops a conflict management framework for DfMA.

• Gap 4: Lack of automated data processing and requirement checking

An automated data collection and requirement-checking system for DfMA prefabricated design has not been explored. Thus, a great amount of manual labor is typically needed to read and process the feedback, check the requirements, and update the model [11]. Furthermore, manual requirement checking can result in multiple versions of the model, which leads to further conflicts and delays. Therefore, this research provides an automated system for data processing requirement checking to enable an efficient and effective DfMA framework.

2. Research Methods

In order to address the four research gaps, this research aims to establish and validate a comprehensive and efficient DfMA-prefabricated design framework. The research methods include three steps.

First, a literature review was conducted to identify relevant research in this field. The literature view aims to summarize the current research on DfMA-oriented prefabricated design and identify the existing gaps. The majority of the literature review results can be found in Section 1.2, and the identified research gaps can be found in Section 1.3. For more information regarding the detailed findings, refer to [26,27].

Next, based on BIM and ontology technologies, this research establishes a comprehensive and efficient DfMA-prefabricated design framework. The specific objectives include the following: (1) identify the potential solutions for improving the interoperability in DfMA-oriented prefabricated design; (2) provide a framework of interoperable communication and information exchange for conflict detection and management; and (3) develop automatic requirement checking. The framework structure is explained in Section 3.

Finally, this research tested and validated the framework on a prefabricated building project as a case study. In this case study, data requirements for each of the stakeholders were implemented into the framework. The automated requirement checking results and conflict checking results were compared with ground truth to validate the accuracy of the framework. Interviews and surveys were conducted with industry stakeholders to evaluate the framework from aspects such as efficiency and the improvement on information interoperability.

The scope of this article includes describing the framework, validating the accuracy of conflict detection and automatic requirement checking, and evaluating the framework using a user-experience the survey. Additionally, the investigations of what methods are best suited for DfMA and the ontology development are excluded from the research.

3. BIM and Ontology-Based DfMA Framework Overview

The framework developed in this research refers to the DfMA-oriented prefabricated design framework proposed by [8] (See Figure 1) and integrates BIM and ontologies to address the four research gaps. The input for the framework is the initial prefabricated information model, and the output for the framework is the finalized prefabricated information model. The initial prefabricated information model is described as the model developed by architectural designers, structural designers, and split designers, which focused on appearance design, strength, and durability analysis. The finalized prefabricated information model is defined as the model that has been evaluated and revised to meet all manufacturing and assembly requirements.

The framework (Figure 2) has six main modules: (1) design module; (2) customer and code module; (3) manufacturer and contractor module; (4) conflict detection module; (5) requirement checking module; and (6) feedback module. The transmission of files and data between the modules is realized through a Cloud database. All intermediate files are also stored in the Cloud. The framework starts with the first three modules (i.e., design module, customer and code module, and manufacturer and contractor module) working simultaneously. Any updates in these three modules will cause the framework to return to the start to incorporate the updates. The conflict detection module works after the customer and code module and manufacturer and contractor module complete. The requirement checking module starts the requirement checking if no conflicts are detected between the design requirement and manufacturing/assembly requirements. Finally, the feedback module accepts and transfers the information from the requirement checking module. If prefabricated information models have passed all requirement checking, the loop ends. Otherwise, the checking results are sent back into the design module.

3.1. Stakeholder Data Requirements

The developed framework focuses on three requirements: design, manufacturing, and assembly. The design requirements come from architectural designers, structural designers, split designers, and customers. The manufacturing requirements refer to manufacturers’ requirements on the components based on their own manufacturing, transportation, and environmental considerations. Assembling requirements refer to contractors’ requirements on the components based on their on-site assembly conditions. Those requirements are applied on the initial prefabricated BIM model (Figure 1).

This research focused on three types of requirements according to data type: quantitative requirement, qualitative requirement, and existential requirement.

• Quantitative requirement: The quantitative requirement defines the comparative relationship between a prefabricated component’s attribute/parameter and a specific quantity value (or quantity range). The comparative relationships include “equal to”, “not equal to”, “more than”, “no more than”, “less than”, “no less than”, and “between”. For example, the requirement “The length of the wall should be less than 7 ft. 6 in. (2286 mm)” means that the “length” attribute of the component “wall” should be less than 7′6″.
• Qualitative requirement: Some of the attributes cannot be measured in quantity. Thus, qualitative requirements indicate that the attribute/parameter of a prefabricated component belongs to a certain category or is equal to a text description. For example, “The heaters should be manufactured by the company named Furniture Country” means that the company “name” attribute of the component “heater” should be “Furniture Country”.
• Existential requirement: It requires the existence of a certain type of prefabricated component. For example, “This modular home should contain heaters” means that component “heater” should exist in the designed modular home.

Additionally, these three were validated during consultation with industry practitioners who also suggested that the requirements they provide to the designers fall into these three categories.

3.2. Prefabricated Component Ontology

Ontologies and BIM are the key technologies to support the framework. Our preliminary research developed a prefabricated component ontology (as seen in Figure 3), which can (1) support the reasoning between rules and ontology instances; and (2) create a gazetteer of all concepts to support the application and interface development. Additionally, RDF offers a unified format for describing individual ontology instances. The readers can refer to [26] for more details about the whole structure and the development process of the ontology.

3.3. Design Module

The design module has three functions: (1) build up the initial prefabricated information model and set the value to model parameters; (2) extract selected information from BIM models and create the corresponding ontology instances; and (3) read and process the results from the feedback module. Although any design software can be used in this framework, this research chose Revit because it provides the platforms for designers to complete the architectural design, structural design, split design, and clash detection. Multiple plugins inside Revit using Python were programmed to facilitate data input and output. Protégé provides the plugin for importing Excel data into ontologies, and users can edit a list of transformation rules that map the Excel data into the ontology. Some specific steps of designers’ works are presented below.

First, the designers can insert various basic manufactured components, such as structural elements, building elements, MEP equipment, and furniture models, into the model. Additionally, designers can use the “Group” function in Revit to combine various basic manufactured components into a prefabricated component with a higher prefabrication level (e.g., modular system).

Next, designers need to set a value on parameters of the prefabricated components in the BIM model. There are three groups of parameters:

• Existing parameter: Some parameters such as “Length”, “Width”, and “Elevation” can be directly obtained since they are built-in parameters of the model.
• Required parameter: Two parameters must be created and input: (1) Each element in the BIM models should be specified in its “Component level”. According to the ontology structure in Figure 3, if the prefabrication level of the component is “manufactured component”, the designers need to clarify its building element type, structural element type, MEP type, or furniture type. (2) Revit assigns a unique identifier “ElementID” for each element. The parameter “ElementID” will be used to locate the element when the results are sent from the feedback module to the design module. Designers can use Dynamo within Revit to automatically create and write the parameters “ElementID” for each component.
• Optional parameter: Some other parameters, such as “Start time”, “Project name”, and “Manufacturer” can be optionally created and input by the designers according to the available project information.

In addition, the plugin inside the Revit exports all the parameters that the designer selects for elements into an Excel file. Then, that exported information will be converted to an RDF/XML file as ontology instances. An example of an RDF graph of an ontology instance is presented in Figure 4. Thus, the plugin in Protégé can convert the parameters of the prefabricated components from an Excel file into ontology instances stored in RDF. Through this Protégé plugin, the designers can define a set of transformation rules to the cells in the Excel. The process from the components to the ontology instances is presented in Figure 5.

Moreover, the other plugin is developed to read the query results from the requirement checking module and present them in Revit. The query results contain the parameter “ElementID”, which is used for searching and locating the non-compliant element in the Revit model. As presented in Figure 6, the plugin provides an interface that enables the designers to automatically locate each non-compliant element. Designers can also check the violating design, manufacturing, or assembly requirements with the elements, and thus they can make changes on it.

3.4. Customer and Code Module

The customer and code module is used for customers and designers to input their requirements on the prefabricated components. Designers can input the requirements on the prefabricated components according to the existing design code. Customers can input their requirements on the component according to their residential requirements such as “the room should have heaters”. In this module, a Python-based interface is designed to facilitate the users to input the requirements. The options and concepts in the interfaces come from the classes listed in the ontology. As seen in Figure 7, the customers and designers need to first specify the prefabrication level of the element. If the prefabrication level of the element is “manufactured component”, the software users still need to specify the building element type, structural element type, MEP type, or furniture type. If the users only identify the component level and element type without further setting the parameter restrictions, this requirement will be regarded as the existential requirement.

Then, the users can choose to set the quantitative or qualitative requirements on any parameters of the components. For example, the users can set the quantitative requirements by choosing the “Comparative relation” (i.e., “equal to”, “not equal to”, “more than”, “no more than”, “less than”, “no less than”, and “between”) and determining the quantity value for parameters. The users can also set the qualitative requirements by choosing the predefined categories or inputting the text description for parameters.

The user interface also provides a link to a website which introduces the concepts of each term appearing in the interface. Moreover, the users can input any number of requirements through this interface, and all these requirements will be stored in an Excel file in the Cloud database.

3.5. Manufacturer and Contractor Module

The manufacturer and contractor module is used by manufacturers and contractors to input their requirements for the prefabricated components. In this module, a Python-based interface has been designed, which is basically the same as that in the customer and designer module. The only difference is that a conflict checking function is added. It can help the manufacturers and contractors check whether their requirements have any conflicts with those existing design requirements. Specifically:

• If conflicts exist, the users will receive both a warning message and the specific conflicting design requirements. The manufacturers and contractors can choose to withdraw or change this requirement.
• If conflicts do not exist, the requirements will be directly sent to the requirement checking module.

3.6. Conflict Detection Module

The conflict detection module aims at detecting the conflicts between design requirements and manufacturing/assembly requirements. The mechanism for the conflict detection is presented in Algorithm 1. This algorithm is applicable for both the quantitative and qualitative requirements. The core thinking is to check whether the value ranges from the requirements have any overlaps. The implementation of Algorithm 1 is based on Python.

Algorithm 1: Function: quantitative requirement conflicts detection

Input: All design requirements, D; All manufacturing or assembly requirement, MA.

Output: All conflicting design requirements, R.

1: foreach d in D do

2:   if MA. Component Level==d. Component Level && MA. Component Type==d. Component Type then

3:    A1=MA. Attribute Set();

4:    A2=d. Attribute Set();

5:    foreach a1 in A1 do

6:      foreach a2 in A2 do

7:       if a1. Attribute Name==a2. Attribute Name:

8:        if a1. Is Quantitative()then

9:           start1=a1.leftbound;

10:          end1=a1.rightbound;

11:          start2=a2.leftbound;

12:          end2=a2.rightbound;

13:          if !Overlap (start1, end1, start2, end2) then

14:           R. add(d, A2);

15:       else if a1. Is Qualitative()

16:         if a1.AttributeValue!=a2.AttributeValue;

17:           R. add(d, A2);

18:

19: //This function is used to detect the overlaps between two ranges

20: Overlap (start1, end1, start2, end2)

21:   return (

22:      start1 <= start2 <= end1 ||

23:      start1 <= end2 <= end1 ||

24:      start2 <= start1 <= end2 ||

25:      start2 <= end1 <= end2

26: )

3.7. Requirement Check Module

The requirement check module focuses on forming SPARQL queries and checking whether the ontology instances meet the collected requirements. The inputs into this module are the requirements from the designers, owners, manufacturers, and contractors. The output should be those non-compliant ontology instances. Some Python scripts are developed to automatically read the requirements from the Cloud database, load the ontologies, form SPARQL queries, and perform SPARQL queries. For example, the SPARQL query for the requirement “The length of exterior wall should be no less than 15 feet, and the height should be more than 20 feet” is presented below. The readers can refer to [26] for more explanations of how the SPARQL queries were formed.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX owl: <http://www.w3.org/2002/07/owl#>

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

PREFIX pco: <http://www.semanticweb.org/ontologies/PreCompoOntology#>

SELECT ?Element ?ElementID ?LengthValue ?HeightValue

WHERE {

?Element rdf:type pco: manufactured_component.

?Element pco:hasElementId ?ElementID. ?Element rdf:type pco:Exterior_wall.

?Element pco:hasAttribute ?Length. ?Element pco:hasAttribute ?Height.

?Length rdf:type pco:Length. ?Height rdf:type pco:Height.

?Length pco:hasValue ?LengthValue. ?Height pco:hasValue HeightValue.

FILTER(?LengthValue <15 || ? WidthValue <20)

3.8. Feedback Module

This module reads the query results from the requirement check module and sends them to the design module. There are three types of feedback:

• If some elements violate certain quantitative or qualitative requirements, a qualitative/quantitative requirement violation feedback including non-compliant elements’ “ElementID” and the corresponding qualitative/quantitative requirements violation will be sent to the design module. The designers can locate the element and make changes in Revit according to the feedback.
• If an existential requirement is violated (i.e., no elements show in the requirement checking result), an existential requirement violation feedback stating that a specific prefabricated component type should exist will be sent to the design module. The designers can add the specific prefabricated component type into the BIM model.
• If all the selected elements meet all the quantitative, qualitative, and existential requirement checks, a requirement passed feedback stating that the current model can be finalized will be sent to the design module.

4. Case Study

4.1. Project Team

A case study on a prefabricated building project was used to test and validate the framework. This prefabricated building is a two-floor hotel located in Gainesville, Florida. The following was the project team: the School of Architecture at the University of Florida was responsible for design work; a prefabricated component factory from Jacksonville, Florida, was responsible for manufacturing and transporting the components; and a construction company from Gainesville, Florida, was responsible for the on-site assembly of the prefabricated components. Since the involved teams were located in different areas, it would be difficult to form a multidisciplinary DfMA team to hold regular team meetings to evaluate the initial design model of the project.

4.2. Initial Model

As presented in Figure 8 and Figure 9, the hotel was composed of two types of rooms modules: large suite and small suite. Thus, their prefabrication level was classified as modular building system (e.g., Level 2 prefabrication level). Each room type was composed of some manufactured components, such as MEP equipment, furniture, structural elements, and building elements. The floor plans of the two room types are presented in Figure 10. After completing the initial prefabricated BIM model, The designers assigned the room modules and manufactured components with the necessary parameters. Specifically, two room modules and all manufactured components were given names in the format of “Element ElementID” (e.g., “Element 612322”).

4.3. Designing Requirements Check

Designers and customers input 53 requirements into the framework, including 3 customer requirements and 50 designer requirements. Part of the requirements and the associated SPARQL query results are presented in

Table 2. Designing requirements example.

Source	Label	Type	Requirements	Result
Customer	C1	Existential	The room should contain a dryer.	N/A
	C2	Existential	The room should contain a washing machine.	N/A
Designer	D1	Quantitative	Columns shall not exceed 16 feet in height.	N/A
	D2	Quantitative	The minimum thickness of walls shall be 8 inches.	N/A

. The customer requirements were basically the existential and qualitative requirements according to their residency requirements. The designer requirements came from design codes (e.g., International Building Code). Based on the query results, it was found that the dryer and washing machine do not exist in the current design model. The designers received the feedback and then added the dryer and washing machine into the both the large suite and the small suite BIM model.

4.4. Manufacturing and Assembling Requirements Check

In this project, the manufacturers had three requirements for the prefabricated components according to their manufacturing equipment size constraint and transportation and vehicle loading constraints; the contractors had two requirements according to their on-site crane lifting capacity constraint (As seen in

Table 3. Manufacturing and assembly requirements.

Source	Label	Type	Requirements	Results
Manufacturer	M1	Quantitative	Component level: modular building system; Weight: no more than 3,000,000 lbs.; Length: no more than 30 ft.; Width: no more than 30 ft.;	Element 684939
	M2	Mixed	Component level: manufactured component; Building element: Exterior_wall; Length: no more than 15 ft.; Height: no more than 12 ft; Width: no less than 0.15ft; Material: Concrete; Weight: no more than 150,000 lbs.; Thickness: no more than 6 inches.	Element 641561 Element 641562 Element 641563 Element 641564
	M3	Mixed	Component level: manufactured component; Building element: Floor; Material type: Wood; Thickness: no more than 6 inches.	N/A
Contractor	A1	Quantitative	Component level: modular building system; Weight: no more than 4,000,000 lbs.; Length: no more than 40 ft.; Width: no more than 40 ft.;	Element 684939
	A2	Quantitative	Component level: manufactured component; Structural element: Roof; Thickness: more than 0.5 ft; Slope: smaller than 0.02	Element 641592

). The conflict detection results and the corresponding changes are presented in

Table 4. Conflicting check results.

Manufacturing and Assembling Requirements	Conflicting Designing Requirements	Changes
M1	None	None
M2	D2	Remove the “Thickness: no more than 6 inches”
M3	C10	Change material type from “Wood” to “Tile”
A1	None	None
A2	None	None

. After the conflict detection, it was found that requirement M2 conflicts with requirement D2 (i.e., the minimum thickness of walls shall be 8 inches). Then, the manufacturers decided to remove “Thickness: no more than 6 inches” in requirement M2. Additionally, the requirement M3 was conflicting with requirement C10, which required the material type of the floor should be “Tile”. Thus, manufacturers changed the material type requirement from “Wood” to “Tile” in M3.

4.5. Final Design

After reviewing the feedback from the manufacturers and contractors, the changes that were made to the building are presented in

Table 5. Design changes after manufacturing and assembly requirement checking.

Element	Component Type	Changes
Element 684939	Modular building system	Reduce the length to 29 feet. Control the weight under the 3,000,000 lbs. Revise the interior layout.
Element 641561, Element 641564	Exterior wall	Reduce the length to 15 feet.
Element 641562, Element 641563	Exterior wall	Reduce the length to 11 feet.
Element 641592	Roof	Increase the thickness to 0.6 feet.

. Specifically, the major design changes were made on the “Element 684939”, which is the large suite model. Its size and interior layout have been significantly revised to meet the requirements. In addition, some other specific manufactured components were also revised: the length of four exteriors walls was reduced and the roof’s thickness was increased. The floor plan of the large suite after changes is presented in Figure 11. This updated BIM model went into the loop again for design, manufacturing, and assembly requirement checking. At this time, all the elements met the manufacturing and assembly requirements, so the final design was determined.

5. Discussion

The following subsections focus on discussing the validation, practical significance, contributions, and limitations of the framework. This research compares the SPARQL query results with the manual checking results to validate the accuracy of requirement checking. A user experience survey was also used to assess different aspects of the framework. The results indicate that the framework can (1) provide efficient and accurate requirement checking and conflict detection; (2) improve information sharing and interoperability; and (3) have good generalization to other applications.

5.1. Framework Validation

In the case study, there were a total of 53 requirements from the designers and customers and 5 requirements from the manufacturers and contractors. The results of the SPARQL queries were compared with those from the manual checking. The correctness rate of the SPARQL queries was 100%. In addition, manual efforts were also used to find whether there were conflicts between manufacturing requirements and design requirements. The results indicated that the conflict detection algorithms can accurately detect all conflicts.

Additionally, a user experience surveying was used to evaluate different aspects of the framework. Four designers, four manufacturers, and five contractors were invited to utilize and evaluate the framework. The participants were sent a link to download and install the Protégé, plugins and interfaces. Then, they were requested to use the software to input requirements, detect conflicts, and test requirement checking. Afterwards, they were requested to rate different aspects of the framework using a five-point scale (from lowest to highest). A follow-up interview was also conducted to ask the participants about their comments on the framework. According to the results in

Table 6. User experience survey results.

Aspect	Designers	Manufacturers	Contractors
User Interface friendliness	4.25	4.5	4.6
User Interface operability	4.5	4.75	4.6
Sufficient instructions	4.25	2.5	2.8
Running speed	2.5	5	4.4
Coverage of information	4.5	3.75	3.2
Improves on working efficiency	4.5	4.75	4.4
Improves on information sharing	5	5	4.8
Future application potential	4.75	5	4.6

, the designers, manufacturers, and contractors were generally satisfied with the user interface friendliness, operability, working efficiency improvement, information sharing improvement, and future application potential of the framework. Some aspects that need further improvement include:

• The designers were not satisfied with the running speed. According to the follow-up interview with the designers, the process of using the plugin in Protégé to convert the parameters of the prefabricated components from an Excel file into ontology instances was too slow. Taking the case project in this research for example, it took around 1 min to transfer 60 elements into ontology instances.
• Both the manufacturers and contractors thought there were not sufficient instructions on their interfaces. They also claimed that there are ambiguities on the term explanations and operating procedures.
• Both the manufacturers and contractors thought coverage of information in the interfaces was limited. Specifically, some parameters or element types were not covered in the developed ontology structure and the options in the interfaces. For example, some manufacturers claimed that they did not find the “Heating capacity” attribute for the component “Air condition”.

5.2. Contributions

This research contributes to existing research in two aspects: (1) the framework improves the information sharing and interoperability for DfMA-oriented prefabricated design; and (2) the framework has good generality when applying to the another project.

5.2.1. Improving Information Sharing and Interoperability

As described in Table 6, the users have high ratings of the framework in terms of the working efficiency improvement and information sharing improvement. Specifically, combined with the results of follow-up interviews, the development is believed to improve the information sharing and communication efficiency in prefabricated design in the following aspects:

• Consistency: The labels and options appearing in the plugins and interfaces all come from the classes defined in the developed ontology. It can ensure the different teams can communicate through clear and consistent terms.
• Independence: Designers, customers, manufacturers, and contractors can input their requirements on the prefabricated components through the interfaces independently, thus reducing the time required to organize and hold multidisciplinary meetings.
• Compatibility: The framework can detect the conflicts between the design requirements and manufacturing and assembly requirements and thus reduce the waste of time caused by disputes.
• Automation: The SPARQL queries can be automatically formed through the built-in algorithms. The users do not need to learn how to use SPARQL languages or be familiar with the structure of the ontology. Additionally, designers can automatically check whether their designs meet the requirements from the manufacturers and contractors using SPARQL queries. The non-compliant elements can be automatically located, and the corresponding violating requirements can be presented for the designers to efficiently make the changes.

5.2.2. Generalization of the Framework

The framework has good generality when applying to another project. This research focuses on the development process of the framework, which demands some manual efforts, such as developing ontologies, creating parameters in Revit, and creating transformation rules to transfer extracted BIM information into ontology instances. When applying to other applications, these manual efforts can be minimized and avoided altogether, specifically:

• The developed ontology can be saved in owl format in a Cloud database, which can be directly used in future applications.
• The created parameters can be saved and loaded when opening a new project in Revit.
• Protégé has the function to save and load the transformation rules.
• The requirements from different disciplines can be stored in the Cloud database, which can avoid repeated input for the same requirements.

In addition, this research is the first to develop a comprehensive DfMA-oriented prefabricated design. The ontology developed in this framework covers various component types and component levels.

5.3. Limitation and Future Works

Although the framework can bring benefits to DfMA-oriented design for industrialized construction, some limitations still exist. Based on our survey result, some limitations include low running speed in transforming the extracted BIM information into ontology instances, lack of instructions in the manufacturers’ interface, and lack of coverage of sufficient information. Consequently, future research can develop an algorithm that enables a faster transformation of BIM information into ontology instances. In addition, a website that contains all explicit descriptions of the knowledge of the prefabricated component ontologies is suggested to be created to help the users better understand the terms on the interfaces. Moreover, ontology developed in this research is a simple prototype ontology. A considerable amount of work needs to be carried out to make it comprehensive and practical.

This research develops several plugins inside Revit for data format input and conversion. Although plugins are important aspects of information interoperability, typically, the burden of developing mapping into neutral exchanges and ontologies falls on the software vendors.

Another limitation is that the current framework only supports requirement checking for a single type of prefabricated component. In an actual project, there could be more complex requirements, such as the spatial relationship between two types of components. Future research should focus on developing the interfaces to support more complex requirements with the assistance of techniques such as Natural Language Processing.

Finally, the last limitation is identified from our follow-up interviews: designers think the adoption of the framework will add to their work burdens while increasing the work efficiency. The designers need to learn how to use the plugins inside Revit to import and export data and use Protégé to transfer the Excel file data into ontology instances. Future research should focus on simplifying the operations for the designers.

6. Conclusions

Industrialized construction is gaining popularity in the industry due to its advantages of reducing pollution, shortening construction time, and increasing safety. However, the current design of industrialized buildings is largely based on the original design system of traditional non-prefabricated buildings, which often lacks the considerations of the manufacturing, transportation, and assembly requirements. Factory regulations, combined with constraints on production and transportation, impose requirements on the engineering design of the prefabricated components. The application of a traditional design system into industrialized construction would affect design alteration and design efficiency. The integration of DfMA into the design process of industrialized construction may help mitigate some of the existing challenges. The existing research on the DfMA-oriented design process for industrialized construction has some gaps, such as lack of methods to improve information interoperability, lack of conflict detection and management, and inefficient data processing and requirement checking. Only when these gaps are addressed can the full potential of DfMA in prefabricated design be realized.

This research develops an ontology and BIM-based DfMA framework for prefabricated design to solve the four research gaps, specifically:

• This research is among the first to propose a comprehensive DfMA-oriented prefabricated design framework using BIM and an ontology. Significantly, this research applies the framework on a case study prefabricated hotel project to validate the feasibility of the framework. The framework can also be extended to other applications due to its good generalization.
• This framework utilizes ontology to collect and process various teams’ requirements in a uniform data format, which improves the information interoperability among the stakeholders. Based on the results of a user experience survey, the developed framework can help improve working and communication efficiency.
• This research proposed an automatic conflict detection and resolution between the design requirements and the manufacturing and assembly requirements. As presented in the results of manual checking, the methods can accurately detect the conflicts between the requirements.
• The other highlight of the framework is automatically checking whether the designed components meet the design, manufacturing, and assembly requirements. Through the manual checking, the proposed automatic requirement checking methods have shown high accuracy and efficiency.

Some limitations still exist, such as the running speed is slow, it only supports requirement checking for single type of prefabricated component, the developed ontology needs to be enriched, and the manual works needed to be reduced. This research can be regarded as an explanatory research in this area, and future research can enhance the developed framework to better serve the construction industry. Significantly, by addressing the research gaps, this research shows great potential in advancing prefabricated component design applications by enabling a more efficient DfMA process.