Abstract
Building information modelling (BIM) is an integrated informational process and plays a key role in enabling efficient planning and control of a project in the architecture, engineering, and construction (AEC) domain. Industry foundation classes- (IFC-) based BIM allows building information to be interoperable among different BIM applications. Different stakeholders take different responsibilities in a project and therefore keep different types of information to meet project requirements. In this paper, the authors proposed and adopted a six-step methodology to support BIM interoperability between architectural design and structural analysis at both AEC project level and information level, in which (1) the intrinsic and extrinsic information transferred between architectural models and structural models was analyzed and demonstrated by a business process model and notation (BPMN) model that the authors developed; (2) the proposed technical routes with different combinations and their applications to different project delivery methods provided new instruments to stakeholders in industry for efficient and accurate decision making; (3) a new material-centered invariant signature with portability can improve information exchange between different data formats and models to support interoperable BIM applications; and (4) a newly developed formal material information representation and checking method was tested on a case study where its efficiency was demonstrated to outperform (i) proprietary representations and information checking method based on a manual operation, and (ii) the model view definition (MVD)-based information checking method. The proposed invariant signature-based material information representation and checking method brings a better efficiency for information transfer between architectural design and structural analysis, which can have significant positive effects on a project delivery due to the frequent and iterative update of a project design. This improves the information transfer and coordination between architects and structural engineers and therefore the efficiency of the whole project. The proposed method can be extended and applied to other application phases and functions such as cost estimation, scheduling, and energy analysis.
1. Introduction and Background
Nowadays, building information modelling (BIM) supports the critical data exchange in the architecture, engineering, and construction (AEC) domain among different models, applications, phases, and stakeholders. BIM can integrate geometric representations with a variety of semantic information of buildings. This contributes significantly to a shift in the method of information documentation and exchange among different types of models in the AEC domain. BIM acts as an innovative technology that connects two-dimensional drawings with three-dimensional models to integrate different lifecycle phases of a building or infrastructure in the AEC domain. The BIM interoperability problem is both a technical issue and a process issue. The technical dimension is reflected in the software workflows using various BIM applications. In the architectural design and structural analysis domains, this mounts to the importation and exportation compatibilities of various BIM authoring tools and engineering analysis software, and the interpretations and analyses of the imported/exported information in these software packages. The process dimension is reflected in the actual use of modelling information between the architectural design and engineering analysis processes. The technical dimension focuses on the model (i.e., how the model is processed during importation/exportation from different software platforms) and the process dimension focuses on people (i.e., how people exchange information through the use of the models).
An engineering model is currently preferably created from scratch rather than adapting the building information models (BIMs) generated previously in a different software platform, because of the information missing and information inconsistency problems between directly converted architectural models and structural models. Missing information can cause uncertain or erroneous structural analysis results. Information inconsistency can cause confusions and misunderstandings between different stakeholders. In order to support interoperability between BIM applications, any missing or inconsistent information during the information exchange must be addressed. Existing research that explored BIM interoperability between architectural design and structural analysis heavily focused on the technical dimension with little or no consideration of the process dimension [1, 2]. There is a lack of a systematic methodology to develop BIM interoperability solutions based on demand analysis. To address that, in this paper, the authors proposed a new methodology that combined the consideration of the (1) technical information transfer process in the project delivery background context, and (2) analysis of information need and gaps, to lay the foundation of application-oriented BIM interoperability investigation. The information gap and need analyses focus on how the information flows between architectural design and structural analysis. An architectural model mainly describes building geometric information and appearance representation of a building. A structural model simulates the performance of structural elements under different types of loads. Both architectural design and structural analysis are key tasks in the process of constructing a building. Business process model and notation (BPMN) provides a set of constructs to support the representation of a business process. It is a notation scheme especially good for high level/domain level process analysis [3]. A BPMN diagram provides a graphical representation, therefore, facilitates an easier understanding of the process among different units within an organization [4]. In this paper, a BPMN model is used to capture the technical information transfer process. Segment-based technical interoperability routes are developed in the context of project delivery methods. The authors identified an urgently needed research task in helping with facilitating the provision of material information. To address that, the authors studied three main types of materials commonly used in a construction project, investigated how they could be provided in BIM, and proposed a new invariant signature-based [5–8] formal material information representation and checking method. A case study was conducted where the material information representation and checking method was applied to a 12-storey concrete frame model. The case study results demonstrated the efficiency of the proposed material information representation and checking method to support information transfer between architectural design and structural analysis, based on its comparison with a manual method.
2. Literature Review
2.1. BIM and IFC Model View Definitions (MVDs) Application
BIM has been theorized by Dr. Chuck Eastman, 45 years ago [8]. In the AEC domain, a widely accepted and matured technical platform, which is based on an open standard, can enable communication and collaboration among different stakeholders without requiring them to have specific skills or proprietary applications. BIM provides the platform to transform the communication of participants in the AEC area from a one-to-one paradigm to a many-to-one paradigm. While BIM interoperability of a system with itself and/or with other systems is a constantly challenging issue in the AEC domain; it needs to be investigated both in the technical dimension and the process dimension [9].
Industry foundation classes (IFC) have been developed by an industry consortium since 1994. Since then, industry context, standardization organization, resource availability, and technology development of BIM applications have exposed the standardization process to a dynamic environment centered around IFC [10]. IFC model view definitions (MVDs) are specification documents that define exchange protocols between different BIM applications, by specifying a set of concepts and relationships needed for the exchange. Therefore, MVD can help BIM developers incorporate IFC compatibility into their software development [11]. An MVD has two main parts: definitions and configurations. Definitions refer to the range of the possible concepts and relationships, whereas configurations refer to how the definitions should be used in a specific application context. For example, in the quantity take-off application context, the model of a concrete wall requires the following three possible relationships to be defined between 3D objects: disjoint, nested, or overlapping [12]. MVD is a useful construct for information checking of IFC data. Using MVD, entity instances (e.g., “IfcMaterial”) could be checked, and a validation report will be created that lists entity instances and their numbers of occurrences [13]. MVD tools provide a platform to implement MVD definitions and concepts. However, attributes of entity instances usually could not be directly checked using the MVD tool (e.g., IfcDoc software).
2.2. BIM Interoperability from Technical and Process Dimension Analyses
From the technical dimension, BIM interoperability indicates the ability to exchange data with other systems without major modifications [14]. BIM enables visualization techniques, such as augmented reality, to be applied to the AEC domain, for goals such as defect management, facility management, and preview of a built environment before construction [15–18]. BIM can be applied to energy modelling and energy simulation as well, where it has been identified that there is a gap in conversations between BIM applications and energy modelling tools during construction management [19, 20]. The integration of geographical information system (GIS) with other techniques (e.g., real-time location system) for BIM applications can improve the interoperability of different data types. For example, the IFC model can be imported into GIS to be further processed [21, 22]. In spite of the fast development of BIM, the AEC domain is still facing the problem of information missing between different BIM models, applications, and systems.
From the process dimension, BIM supports project management in procurement, construction, prefabrication, and facility management, among others [23, 24]. Although BIM-based construction networks improved the communication among geographically separated participants, how to maintain collaboration that comes from multiple disciplines and organizations is still a problem to solve [25–27]. With the development of a growing number of universities beginning to offer BIM-related courses in their AEC related programs, BIM becomes a promising vehicle for the education sector to introduce new information technology [28, 29]. To catalyze the development and harnessing of benefits mentioned above, information inconsistency between different stakeholders needs to be addressed to meet the BIM interoperability goal.
2.3. BIM for Architectural Design and Structural Analysis within the Context of Project Delivery Method
The integration of data, processes, and functions in a construction project is a major challenge that makes a technical development restrained by its process context [30, 31]. In construction, there are many different types of project delivery methods which sets the tone of a process context such as design-bid-build (DBB), design-build (DB), construction management at risk (CMR), construction management agency (CMA), construction management multiprime (CMMP), and integrated project delivery (IPD). At the high level, these methods can be organized into two categories based on whether the design and construction contracts are combined or separated, which dictate if the interaction between architectural design and structural analysis can be direct: (1) in DB and IPD, the design and construction contracts are combined, which allow architectural design and structural analysis to have direct and frequent interactions, whereas (2) in DBB, CMR, CMA, and CMMP, the design and construction contracts are separated, which render the interactions between architectural design and structural analysis indirect and less frequent. In practice, the selection of the best project delivery method depends on many factors such as the type of project (e.g., residential, commercial, and industrial), the experience and preference of the owner and other stakeholders on different types of design and construction contracts (e.g., combined or separated), the weights of construction cost, schedule, quality, and financial risk in their considerations, the available physical and intellectual resources, etc. [32, 33]. In the existing project delivery practice, an architectural model could not be directly used as a structural model. Structural engineers need to abstract useful information from the architectural model (or from the architects) to support the development of a structural model [34]. In addition, among all project delivery methods, the collaboration between architects and structural engineers is important, and their interactions are most likely to be frequent and iterative [35, 36].
2.4. Limitations of Previous Research
From the technical dimension, although BIM has shown profound positive effects in the AEC domain, information missing and inconsistency between different software, platforms, systems, or applications remain challenging. How to quickly identify the missed information and how to bridge the gaps between different information representation methods are essential for BIM interoperability, which request new approaches to support interoperable BIM both at the information level and at the application level. From the process dimension, different project delivery methods have different contract and organizational structures, which in turn forms different information communication/interaction loops. How to effectively integrate interoperable BIM technologies into such communication/interaction loops need to be considered at any phase of the lifecycle of a building or infrastructure project, the result of which could provide a new instrument for decision making to support BIM interoperability.
3. Research Methodology
At the information level, the BIM interoperability problem revolved around identifying information missing and information inconsistency between different data formats, platforms, and applications. At the processing level, BIM interoperability problem focuses on how to leverage techniques, skills, and methodologies to develop roadmaps for interoperable BIM applications. At the service level, the BIM interoperability problem requests user-friendly solutions for stakeholders in the industry to use for supporting their efficient and accurate decision making. To address the BIM interoperability problem by combining considerations in both the technical dimension and the process dimension, the authors propose a six-step method as explained below: Step 1: (BIM Application Phases/Functions Selection). This step defines two application phases/functions between which BIM interoperability will be studied. Example application phases/functions include architectural design, structural analysis, cost estimation, and energy simulation, among others. Step 2: (BPMN Generation). This step identifies the needed information transfer and communication between different stakeholders (e.g., architects and structural engineers) and creates a BPMN correspondingly for project delivery. In this step, the intrinsic and extrinsic information transferred between different models (e.g., architectural model and structural model) are demonstrated and analyzed to support BIM interoperability at the information level. In generating the BPMN, procedures to produce both models will be investigated. Step 3: (Technical Routes Analysis for BIM Interoperability). This step analyzes the BPMN and literature from the technical angle of view and identifies possible route segments for BIM interoperability between selected phases/functions. The developed technical routes with different combinations provide a new instrument for decision making from the process dimension for the purpose of information transfer. The proposed technical routes provide the backbone of the information transfer to support interoperable BIM applications. Step 4: (Information Need and Gap Analysis). Information missing and inconsistency takes a central position in the BIM interoperability problems that need to be solved between different formats, platforms, and applications. Therefore, this step focuses on information missing and information inconsistency analysis (i.e., gap analysis) during the information transfer between different phases/functions based on data analysis, and identifies information representation and checking needs for IFC-based BIM interoperability. In this step, the authors analyze the information acquisition of different types of models and set the tone of the BIM interoperability solution. Step 5: (Solution Development). This step develops an augmented model view definition (MVD) model with customized algorithms to help check an IFC model for meeting specific information requirements to fill in the gap identified in Step 4. In addition, an invariant signature-based information representation method and its application on different project delivery methods help define augmented model view definitions (MVDs) with customized algorithms to fulfill information checking and validation goals. It provides an information representation and checking environment to process information between different models, which facilitates information communication efficiency and accuracy. Step 6: (Case Study Evaluation). This step evaluates the information representation and checking method by implementing developed checking MVDs/algorithms and applying them to a case study. The use of the developed checking MVDs/algorithms will be comparatively evaluated with a pure manual approach. The evaluation helps demonstrate if the proposed method will bring benefits to BIM applications from efficiency and accuracy perspectives.
4. Experimental Results and Discussion
4.1. Step 1: BIM Application Phases/Functions Selection
BIM information is exchanged between different applications at different phases of a project. There are different types of building information models (BIMs) for different applications at the design stage of a construction project, including architectural models, structural models, MEP models, energy analysis models, and cost estimation models, among others. In this paper, the authors selected two application tasks at the design phase-architectural design and structural analysis, because of the following: (1) both applications belong to the design phase, and therefore, it is expected to be easier for collaboration to happen comparing to two application tasks that belong to different phases such as the architectural design in the design phase and facility management in the operation phase; (2) the collaboration between architectural design and structural analysis is usually the first collaboration that happens in a project team; and (3) an effective collaboration between architectural design and structural analysis lays the foundation for other further collaborations (e.g., collaboration between architectural design and cost analysis) to succeed. Architectural design plays an essential role in creating the representational model (i.e., BIM) for a construction project [37]. Structural analyses explore the various stresses, strains, and displacements of the building elements. Currently, it is easier to create a structural analysis model from scratch rather than adapting from the corresponding architectural model [38]. Seamless information exchange between architectural design and structural analysis models could improve coordination effectiveness between architects and structural engineers and bring benefits in time and cost savings to the project team.
4.2. Step 2: BPMN Generation
The authors analyzed the information transfer and communication between architectural design and structural analysis applications and summarized a BPMN that describes steps for creating an architectural model and a structural model, with information exchange between the two models (Figure 1). Solid-line arrows represent step sequences for model creation processes. Dashed lines show information transfer between different steps or models. Information from earlier steps in each model will be saved and delivered to the following steps. The shaded area (i.e., create architectural columns-create doors-create windows-create floors-create ceilings-create stairs) in the process of creating an architectural model represents composite subprocesses, where detailed components of an architectural model are developed. A structural model will be created based on the information from the architectural model, such as geometric information and material information. For example, walls and roofs from an architectural model provide geometric information that can be used as references in the creation of the corresponding structural model. The first step in the process of creating a structural model is a composite subprocess, which includes simplifying geometric information and maintaining material information from an architectural model. For example, a beam or column is represented by simplifying its geometry into a straight line in the structural model without losing beam or column material features. The other information not readily transferred from the architectural model is then added. The nodes connection information is shown by points in the structural model while specifying the connection types. Geometric information and material information will be saved and delivered to later steps. Material parameters may need to be inputted manually to conduct structural analysis. An “envelope” symbol represents the overall message flow between an architectural model and a structural model. The BPMN represents the information transfer between different models and demonstrates that the intrinsic information of an architectural model can be the extrinsic information of a corresponding structural model (e.g., material information), which reflects potential BIM interoperability problems at the information level. The two model-development processes are usually conducted in different software by different personnel. Efficient information exchange between the architectural software and structural software and between the architect and structural engineer is, therefore, important.
4.3. Step 3: Technical Routes Analysis for BIM Interoperability
Based on analysis of most recent existing literature regarding BIM interoperability between architectural model and analysis model from technical and process perspectives (Table 1), it was found that most of the existing research only focused on developing roadmaps from the technical perspective, for example, developing software tools, system architectures, and information transfer mechanisms to support interoperable BIM applications [39–41, 9]. Other researchers solely focused on collaboration and integration framework of AEC projects to improve BIM interoperability [42–44]. There is a lack of systematic investigations in solving the information transfer problems from the technical dimension in the context of the process dimension to support BIM interoperability. To address the BIM interoperability issue that is initiated from the technical dimension in the context of the process dimension, the authors identified and proposed the following six technical route segments of interoperability between architectural design and structural analysis (Figure 2). A route for BIM interoperability would be a combination of one or more route segments to form a closed loop for information transfer. For example, 1-4-3 is one such technical route where information can be directly transferred from a proprietary architectural BIM to a proprietary structural analysis model; then, the structural analysis model can be exported to IFC and read back to the proprietary architectural BIM platform. To illustrate that an architecture model can be developed and saved in architectural design software (e.g., Autodesk Revit), in which the information could be directly read by compatible structural analysis software (e.g., Autodesk Robot); then, the structural analysis model that is developed based on the information from the architectural model can be saved and exported as an IFC model, which can be read back to the architectural software. In this process, for instance, the dimensional information of a beam element in the architectural model can be transferred as values of x, y, and z coordinates to the corresponding developed structural analysis model; then, the dimensional information in a structural analysis model can be exported as an entity instance “IfcCartesianPoint” in an IFC file, which can be imported and read back as dimensional information to architectural design software (e.g., Autodesk Revit).
In project delivery methods CMR and IPD, because the built-in collaboration enables architects and structural engineers to work together with other stakeholders as one team, the communication and negotiation between them and with the owners at an early stage of a project make it possible to identify/select architectural and structural software to use so that Route 1-6 becomes possible. For example, in CMR and IPD project delivery methods, the architects and structural engineers could work together to select compatible software both for architectural design and structural analysis (e.g., Autodesk Revit/Robot). In this process, a developed architectural model could be saved as a DWG format model and imported directly into the analysis software for structural analysis. In project delivery methods DBB and CMMP, however, because the owner or owner’s representative establishes contracts with the different stakeholders separately, it is more difficult to specify compatible architectural or structural software to use for the architects and structural engineers. Therefore, the Route 2-5 is more feasible. For example, an architectural model created by an architect could be saved and exported to IFC format. Structural engineers could import the IFC file into a structural analysis tool to get the information (e.g., geometric information and material information) to conduct further analysis. In this process, the exported IFC file can be a bridge between architectural model/architectural design and structural model/structural analysis to support information transfer of interoperable BIM applications. For project delivery methods DB and CMA, although the owner does not hold all contracts individually and directly, Route 2-5 is still feasible. Therefore, 2-5 could be a potential solution for all project delivery methods if the quality of information transfer in this route can be guaranteed.
4.4. Step 4: Information Need and Gap Analysis
Based on analysis regarding information need and provision for architectural design and structural analysis at the model level, the authors summarized the following types of information needed in structural analysis/structural model: geometric information, loads information, material information, connection type information, and boundary conditions.
Example types of information provided in architectural design/architectural model are elevation and grids information, geometric information (e.g., interior/exterior wall, columns, doors, windows, floors, roofs, and stairs), and material information (e.g., material name, colour, and texture information).
Between information missing and information inconsistency, the authors focus on the information missing problem, because this problem originates from (and roots in) the information generation process, e.g., designer or the BIM authoring tool (information provider) did not include the information, rather than coming from proprietary software or processing algorithms. In contrast, information inconsistency is more of a software implementation problem. Therefore, the information inconsistency problem needs to be solved software by software, whereas the information missing problem is possible to solve with automation and intelligent methods. According to Eastman et al. [49], there are three information providers in BIM: designer, derived data, and simulation or analysis. At the model level, material and geometric information are the essential parts of building elements based on the above-mentioned analyses. The authors argue that the information provider of the material information should be the designer/architect during the architectural design phase, either directly or indirectly together with geometric information of building objects for further use (e.g., structural analysis). Geometric information has been well studied in the literature, and material information representation and analysis is identified as a gap [41, 45].
4.5. Step 5: Solution Development
To support material information representation and coverage, the authors analyzed selected AEC software in terms of their material property settings in IFC based-BIMs (Table 2), which is a necessary step in both architectural design and structural analysis. In some software, materials can be selected directly, such as SolidWorks, which, however, is not specifically designed for civil structural analysis. In some software, only limited materials can be selected, for example, Graytec Advanced and SCIA software only include steel, concrete, and timber materials. Although some finite element analysis (FEA) software, such as ANSYS and ABAQUS, have been widely used for structural analysis, they have certain limitations when used for civil structural analysis. E.g., they can only be used to analyze small structures. In addition, the graphical user interface and application programming interface of FEA software need improvement in terms of information representations in civil engineering to be better used for civil structural analysis purposes [50, 51].
To successfully represent material information in the BIMs, the authors analyzed the needed material information in different analysis scenarios and summarized the needed material properties in each scenario into the authors’ developed invariant material signature: mass, cross-sectional area, volume, mass density, stress, strain, shear stress, shear strain, shear modulus, Young’s modulus, thermal expansion coefficient, and Poisson’s ratio [48].
Based on the proposed material signature concept, the authors developed invariant material signatures for three main types of materials–steel, concrete, and wood. Figure 3 illustrates the detailed properties of these invariant material signatures.
From the process dimension, in different project delivery methods, the architects and structural engineers may choose software that may or may not be directly interoperable. Different interoperability scenarios will affect the possible technical routes to be used. For example, Route 1-6 (i.e., proprietary architectural model - > proprietary structural analysis model - > proprietary architectural model) become possible if the negotiations between architects and structural engineers and with the owners at an early stage of a project successfully identify selected architectural and structural software to use. In Route 1-6, compatible software platforms provide proprietary channels to enable information and model transfer, but the limitations regarding material information missing and inconsistency still need to be addressed (Table 2). Otherwise, the Route 2-5-4-3 (i.e., proprietary architectural model - > IFC - > proprietary structural analysis model - > IFC - > proprietary architectural model) is more feasible. In Route 2-5-4-3, the IFC model works as an intermediate data representation to support information and model transfer, which provides a new way to bridge architectural design and structural analysis tasks at the design phase.
The proposed material information representation method (i.e., the invariant material signatures) can be implemented for both Route 1-6 and Route 2-5-4-3. The authors further leveraged technical BIM interoperability Route 2-5-4-3 to develop an IFC-based implementation, as providing solutions to direct information transfer between proprietary software (i.e., Route 1-6) has to be conducted by the corresponding software companies. Similarly, the information inconsistency problem also has to be addressed by corresponding software companies even if an IFC-based workflow is used, by refining their exportation/importation to/from IFC or other formats to make sure it is error-free.
An IFC file not only contains geometric information of building elements, such as beams, columns, slabs, and walls, but also contains attributes for each object describing their physical and functional properties such as material properties and occupancy types. Figure 4 shows an example of a partial IFC file. In Figure 4, each line is representing an IFC entity and each argument in the parenthesis represents an attribute of this entity. For example, line #80 is one entity in the IFC file that represents material properties. In this entity, “#80” is its data line number, and “IfcExtendedMaterialProperties” is the name of the entity. “STD-Concrete” is one attribute value that is representing the name of an associated material. Material information such as material name can be extracted from such entities in the IFC physical file through analysis of a building element. For example, an “IfcBeam” can be linked to its related material entity (i.e., “IfcMaterial” in IFC file), which can be further related to other entities using “IfcRelAssociatesMaterial” [52]. Detailed material properties in the IFC files are defined by the entity “IfcPropertySingleValue.” There are four attributes of “IfcPropertySingleValue”: “Name,” “Description,” “NominalValue,” and “Unit.”
Figure 5 shows a material property representation implementation diagram of a 12-storey building model in IFC, which was tested in the case study (Figure 6). It shows that, in this IFC file, any information related to material properties is rooted in an “IfcExtendedMaterialProperties” entity. There are four directly related entities which are “IfcMaterial,” “IfcPropertySingleValue,” “IfcText,” and “IfcLabel” to represent material property details. There are four different types of material properties representations (attributes) in the entity of “IfcPropertySingleValue,” they are “IfcIdentifier,” “IfcText,” “IfcValue,” and “IfcUnit,” which represent the material name, material description, nominal value of material property, and unit of value, respectively. Through the proposed invariant material signatures, IFC representation could represent material information in both the architectural model and the structural model in a consistent way.
The authors analyzed the IFC model regarding material information representation implementation in two versions: IFC2X3 and IFC4, and developed corresponding MVDs in IfcDoc software [52]. Attributes of the same entity (e.g., “IfcMaterialProperties”) could be different between the two versions, e.g., in the IFC2X3 version, only the attribute “Name” is included in the “IfcMaterialProperties,” whereas in the IFC4 version, it has “HasExternalReferences,” “Name,” “Description,” “Properties,” and “Material,” five attributes in total. There is no relationship between attributes of the “IfcPropertySingleValue” entity and the “IfcMaterialProperties” entity in the IFC2X3 version. Whereas, in the IFC4 version, attribute “Properties” is the connection between the “IfcPropertySingleValue” entity and the “IfcMaterialProperties” entity (Figures 7 and 8). However, information from these different versions of IFC could all converge in our invariant material signatures.
Furthermore, because the IFC2X3 version has its limitations for model representation, some of the entities could not be used in the IFC2X3 version (Figure 9). As Figure 9 shows, some entities such as “IfcExtendedMaterialProperties” could not be defined in the IFC2X3 or IFC4 versions. Some entities such as “IfcMaterialProfile” and “IfcMaterialDefinition” could not be defined in the IFC2X3 version but could be defined in the IFC4 version. Its structure and relationships were also different from the IFC4 version. For example, there were three attributes “Name,” “HasRepresentation,” and “ClassifiedAs” for the entity “IfcMaterial” in the IFC2X3 version. But there were nine attributes “AssociatedTo,” “HasExternalReferences,” “HasProperties,” “Name,” “Description,” “Category,” “HasRepresentation,” “IsRelatedWith,” and “RelatesTo” for the entity “IfcMaterial” in the IFC4 version. Based on the structure of IFC4, it could represent more information because it incorporated more abundant entity attributes than IFC2X3.
The authors proposed a framework of material information checking based on augmenting the above MVD models with customized algorithms, as well as based on the proposed invariant material signatures. Among the three main types of materials discussed in this paper, the only difference in their MVD validating results would be the number of entities, because the detailed material information is contained in the “Name” and “NominalValue” attributes of the “IfcPropertySingleValue” entity. E.g., for steel material, seven required entities are checked that contained seven parameters: MassDensity, PoissonRatio, ShearModulus, ThermalExpansionCoefficient, UltimateStress, YieldStress, and YoungsModulus. For concrete material, six required entities are checked for six corresponding parameters: MassDensity, PoissonRatio, ShearModulus, ThermalExpansionCoefficient, CompressiveStrength, and YoungsModulus. Therefore, the authors picked one (i.e., concrete material) as an example. As part of the material information checking framework, the authors developed an IFC-based material information checking algorithm, with a special focus on checking “IfcExtendedMaterialProperties,” “IfcMaterialSelect” entities and detailed parameters of steel, concrete, and wood materials in the AEC domain. Figure 10 shows the flow diagram of this customized material information checking algorithm for augmenting MVD-based checking. The algorithm runs three main steps as follows: (1) check IFC entity instances (i.e., “IfcExtendedMaterialProperties”, and “IfcMaterialSelect”) based on MVD constraints; (2) extract material types based on “IfcMaterial” entity instance; (3) check specific material parameters from “IfcPropertySingleValue” entity instances based on different material types. This algorithm will terminate after all the material parameters are checked. The results regarding what specific entity information and material parameter information exists or does not exist will be printed out in a report. Through the developed material information checking algorithm, the missing material information could be identified and used to inform the IFC model developer and user.
4.6. Step 6: Case Study Evaluations
The authors chose a 12-storey concrete model (Figure 6) as the case study model to test the material information representation and checking method. There were three types of material information entities in the IFC model: “IfcMaterial,” “IfcExtendedMaterialProperties,” and “IfcPropertySingleValue.” The results (Figure 11) showed how the six-detailed material parameters of the concrete material in our invariant material signatures were represented, where the highlighted contents showed such material parameter representation details.
Depending on the software in use, manual information transfer may cover all required information, but it is time-consuming and error-prone. Model size is another factor that will affect the information transfer results and a larger model size could significantly increase the needed manual information transfer time. To evaluate the proposed method in facilitating information transfer between architectural design and structural analysis, the authors compared the proposed method with manual information transfer from the time efficiency perspective. A manually developed gold standard was used as ground truth in the evaluation, which included the material information input for structural analysis from an architectural model. The proposed invariant material signatures were implemented in IFC2X3 representations based on the IFC model that was exported from a BIM application software, to transfer material information and their parameters to the corresponding material signature. In this case, the model was exported to the IFC2X3 version to follow industry practice. Although IFC4 is a more advanced version comparing to IFC2X3 as discussed in Step 5, IFC 2X3 still dominates practical use in the industry, due to its massive market penetration and applications that follow it. The Coordination View 2.0 of IFC2X3 is split into two MVDs in IFC4: (1) the Reference View, which is mainly for viewing and coordination purposes and referencing domain models to each other; (2) the Design Transfer View, which is for exchanging IFC models to be used for further design and evaluation tasks. In practice, the Design Transfer View for IFC4 is not fully available, and Coordination View 2.0 for IFC2X3 cannot be fully replaced by the Reference View of IFC4 per se [53]. To address that, the authors proposed the material signature for which IFC2X3 and IFC4 versions of BIMs could be converged. Table 3 shows the IFC-based invariant material signatures as the destination representations of the conversion process. The first and last columns in Table 3 represent “Name” and “NominalValue” attributes for each parameter in IFC data, which are related to material definitions. It was not necessary to define every attribute in the entity based on the IFC schema when the model was created. But the “Name” and “NominalValue” attributes must be defined in the IFC file of a model (i.e., an instantiated physical file).
The authors compared the time consumption of the proposed method with that of a manual information transfer. In the manual information transfer, the interfaces of Solibri Model Viewer and Autodesk Revit 2018 were used. The authors imported the test case model in the software and clicked through each element to add their material information in the property panel. The manual information transfer took 11 minutes to finish. The time could be further increased significantly with model size and complexity because the engineers need to click through each element to identify and assign the detailed material parameters to them and then document the material information for further analysis. In comparison, the proposed method enables automated and efficient conversion and transfer of the material information between architectural models and structural models, based on invariant material signature representations using IFC. In the IFC format, the model could use “Name” attribute of “IfcMaterial” entity instance to represent/store material types (e.g., steel, concrete, and wood) and use “Name” and “NominalValue” of “IfcPropertySingleValue” entity instance to represent/store material parameters (e.g., mass density and Young’s modulus). Using the proposed method, all the material information (i.e., material type and its parameters) could be successfully represented, processed, and analyzed (e.g., structural analysis). Table 4 shows the performance comparison of these two methods.
Figure 12 shows the IFC model validation/checking results using the MVD augmenting algorithm. The authors implemented the algorithm using IfcOpenShell library, which is an open-source library for accessing and processing IFC data. The results showed that the six-detailed material parameters of the concrete material were successfully checked by the MVD augmenting algorithm. The highlighted content showed that “IfcMaterialSelect” entity was not found, whereas “IfcExtendedMaterialProperty” and six material parameters were successfully found and extracted in the IFC model. The total time consumption of running augmented algorithm was 48 seconds in a computer with core i5 dual-core processer and 8 GB RAM, which could be further reduced with a more powerful machine. In contrast, the manual information checking process took 4.2 minutes even after leveraging the search function in a text editor. Table 5 shows the performance comparison of these two methods.
5. Conclusions
In this paper, the authors proposed a six-step research methodology to analyze and address BIM interoperability problems and used it to analyze BIM interoperability between architectural design and structural analysis. Six common project delivery methods were taken into account as the background context, and a BPMN diagram was created based on the transfer and use of modelling information between architectural models and structural models in the architectural design and structural analysis processes. Six technical route segments were summarized to explain any BIM interoperability application between the architectural design and structural analysis processes. To facilitate such interoperability, the authors devised invariant material signatures and developed material signatures for three common construction materials. Then, they developed a formal material information representation and checking method in a systematic way to help solve the material information gap identified through the experiment. The advantage of the proposed material information representation and checking method was demonstrated in a comparative experiment with manual information transfer and checking through a case study. It shows that applying the proposed material information representation and checking method to a construction project could improve information exchange between the architectural models and the structural models for facilitating communication efficiency between architects and structural engineers, therefore, bringing the time and cost benefits to the entire project delivery process. In the process dimension, the proposed technical routes with different combinations and their applications to different project delivery methods provide new instruments for stakeholders in the industry to use for supporting their decision making. As a result, it enables the interaction between architects and structural engineers to be more efficient and therefore more frequent to contribute practical impact in a project process not only for a shorter schedule and faster information delivery but also for a better design and safer structure.
5.1. Contributions to the Body of Knowledge
This research is one of the first systematic explorations of BIM interoperability between architectural design and structural analysis following a new six-step research methodology that was targeted at supporting BIM interoperability research and development. This research contributes to technical routes by summarizing six-route segments of BIM interoperability between architectural design and structural analysis. A combination of one or more route segments could form a closed loop for information transfer to support BIM interoperability, which is what the AEC industry ultimately needs. From the process dimension, the technical route segments with different combinations for information transfer and their applications to specific project delivery methods provide new instruments to stakeholders in the industry for efficient and accurate decision making. The gap analyses regarding information missing and information inconsistency between architectural models and structural models were conducted to find that, in some situations, such as the technical route from proprietary architectural BIM to IFC and from IFC to proprietary structural analysis model, material information could be missing. The authors developed gap analyses of material information between architectural models and structural models and proposed a new set of invariant material signatures and a corresponding material information representation and checking method. The proposed material information representation and checking method could improve information transfer between architectural design and structural analysis to support BIM interoperability in different project delivery methods. The case study results showed that the proposed method could improve information exchange efficiency between architectural design and structural analysis to facilitate BIM interoperability. In addition, the proposed method can be adapted to facilitate the information flow between any two stages of the lifecycle of a building or infrastructure (e.g., roadway, bridge, and culvert) project (e.g., between preconstruction stage and postconstruction stage to deal with the maintenance issues).
The impact of applying this research in the AEC domain could be far-reaching. This research provides a formal invariant signature-based material information representation and checking method to support BIM interoperability. This method facilitates information exchange between architectural models and structural models, which helps improve the information transfer and coordination between architects and structural engineers and therefore the efficiency of the whole project. The proposed method can be extended and applied to other application phases and functions such as cost estimation, scheduling, and energy analysis.
5.2. Limitations and Future Work
The authors acknowledge the following limitation of the proposed formal information representation and checking method in its current shape. Although the proposed method was tested in representing and checking required material information for information transfer between an architectural model and a structural model, how it will perform in representing and checking other types of information, such as analysis results information, needs to be further explored. In future work, the authors plan to expand the proposed method in representing and checking other types of information such as logistic information and in different interoperability scenarios such as between architectural design and energy simulation.
Data Availability
All data generated or analyzed during the study are available from the corresponding author upon request.
Disclosure
The opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation (NSF).
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
The authors would like to thank the National Science Foundation (NSF). This material is based on work supported by the NSF under Grant No. 1745374.