Parallel computing-based online geometry triangulation for building information modeling utilizing big data

Automation in Construction 107 (2019) 102942

Contents lists available at ScienceDirect

Automation in Construction journal homepage: www.elsevier.com/locate/autcon

Parallel computing-based online geometry triangulation for building information modeling utilizing big data

T

Xiaoping Zhoua, , Jichao Zhaob, Jia Wangc, , Xiaoyuan Huanga, Xiaofei Lid, Maozu Guoa, , Peng Xiee ⁎

⁎

⁎

a

Beijing Key Laboratory of Intelligent Processing for Building Big Data, Beijing University of Civil Engineering and Architecture, Beijing 100044, China CNPC Managers Training Institute, Beijing 100096, China c Beijing Engineering Research Center of Monitoring for Construction Safety, Beijing University of Civil Engineering and Architecture, Beijing 100044, China d China Academy of Transportation Sciences (CATS), Beijing 100029, China e Beijing Waterworks Group Co., Ltd., Beijing 100038, China b

ARTICLE INFO

ABSTRACT

Keywords: Building information modeling Industry foundation classes Parallel computing framework Geometry triangulation Big data

Building Information Model/Modeling (BIM) upgrades the digitization of buildings from 2D to 3D and has become a common paradigm in architecture, engineering, construction, operations, and facility management (AECO/FM) industry. However, embedding BIM in decision support systems is still a challenge because the BIM standard (Industry Foundation Classes, or IFC) is complex, and the geometries in BIM cannot be directly rendered in decision support systems, e.g., web and mobile-phone applications. Current efforts mainly focus on rendering BIM triangulation data, and limited studies investigate solutions solving quite long running time and enormously large memory usage in BIM triangulation process, especially in big BIM files. This study addresses this issue by introducing a parallel computing framework and providing an online geometry triangulation service. First, the reference relationships among the BIM objects were modeled as a graph according to the IFC specification. Second, the original large IFC file was split into several small independent IFC files in which all geometric objects that share the same shape representation were aggregated. Finally, the small separate IFC files were assigned to and triangulated in different computers in a parallel computing cluster. Experiments showed that the proposed online service could greatly reduce memory usage and time consumption when triangulating the geometry of BIM objects. Processability has become a critical issue for BIM in the era of construction Big Data. The proposed scheme can triangulate big BIM files efficiently using limited memory and thus can dramatically improve the processability of BIM Big Data.

1. Introduction Building lifecycle management (BLM) [1] has historically been and still remains an open research topic. Building Information Model/Modeling (BIM), which systematically captures multi-dimensional computeraided design (CAD) information to support multidisciplinary collaboration among stakeholders [2], is an emerging and promising technology for BLM. Generally, a BIM model is defined as “the total sum of information” about a building in digital form [3], which contains not only spatial/geometric data but also a great amount of engineering data accumulated throughout the lifecycle of a building. By providing a shared knowledge resource for information about a facility, BIM enables data interoperability and collaboration among stakeholders during its lifecycle [4]. Currently, BIM has been used in almost all stages of BLM, including design collaboration [5], BIM-based n-dimensional (nD)

⁎

management [6], and facility management [7], to name a few. BIM has become a common paradigm in architecture, engineering, construction, operations, and facility management (AECO/FM) industry [8]. BIM is usually expected to have six features: digital, spatial, measurable, comprehensive, accessible, and durable [9]. Recently, Jiao et al. [10] argued that “process-able” should also be added to the BIM definition from the perspective of computer science because the volume of BIM keeps increasing and becomes extremely large as ongoing projects proceed and new projects launch. Hence, the ability to process large-scale BIM data, called processability in this study, has become a crucial issue for BIM. Processability means that the BIM data should be parsed, computed, and analyzed efficiently in acceptable time with limited computing resources. For instance, to apply BIM to a Web-based collaboration system [11,12], the BIM files designed in professional design tools should be computed accordingly and embedded in the

Corresponding authors. E-mail addresses: [email protected] (X. Zhou), [email protected] (J. Wang), [email protected] (M. Guo).

https://doi.org/10.1016/j.autcon.2019.102942 Received 30 August 2018; Received in revised form 13 July 2019; Accepted 29 August 2019 0926-5805/ © 2019 Elsevier B.V. All rights reserved.

Automation in Construction 107 (2019) 102942

X. Zhou, et al.

collaboration system. Obviously, processability is a critical factor to measure the applicability of BIM in lifecycle decision support systems. BIM data are typically 3D geometrically encoded, computation-intensive (graphics and Boolean computing), compressed, in diverse proprietary formats, and intertwined [10]. 3D geometric data are one of the most primary yet most compute-intensive data in BIM. Usually, the 3D geometric data are represented by at least one of the following models: the Boundary Representation (Brep), the NURBS, the Constructive Solid Geometry (CSG), or the Swept Solid Model (SweptSolid). Admittedly, these technologies provide powerful abilities to describe all kinds of shapes in a compressed format. However, the use of hybrid 3D geometric representations also brings disadvantages. One of the crucial problems is that these 3D representation models cannot be directly rendered in many scenarios. For example, due to the limitations of OpenGL ES and WebGL, Web systems and mobile phone applications cannot support the rendering of complex solid geometry descriptions. This triggers the primary demand to triangulate the geometry in BIM data. In addition, the developers must obtain enough knowledge about the convoluted definitions of geometry in BIM, which also increases the difficulty of BIM applications. This study focuses on the geometric triangulation problem of BIM. The Industry Foundation Classes data model (IFC) [13] is the internationally accepted specification for BIM. Without loss of generality, it is assumed here that the BIM data are expressed by an IFC file in this study. Currently, some studies [14–16] have developed BIM triangulation tools that convert the geometries in BIM data to triangle meshes. With these tools, the developers can concentrate on growing their business without needing to understand the complex geometric definitions in BIM data. However, at least two issues remain to be addressed to improve the processability of BIM when triangulating BIM Big Data.

Exploration of geometric triangulation for big BIM files can lay the foundation for studies on BIM in the era of construction Big Data [19]. To the best of the authors' knowledge, the augmented version of MapReduce [10], called AMR, is the only effort to address the processability problem of BIM. AMR first partitions the big IFC file by grouping and dividing the BIM instances according to the floor into data splits. Then, the obtained data splits are sent and computed in a MapReduce framework. However, AMR ignores the BIM instances that are not aggregated into a floor. Moreover, many BIM instances on different floors share the same geometric representation. If these BIM instances are partitioned into the same data split, then the triangulation process can be speeded up. This study aims to address the processability problem of BIM triangulation by introducing a parallel computing framework and providing an online BIM triangulation service. Because this study focuses on the 3D triangulation problem, only the geometry is discussed. Without specification, the text properties, which are also defined in IFC, are ignored. The remainder of the paper is organized as follows. Section 2 discusses related work. Section 3 provides the necessary definitions and preliminaries, and Section 4 presents the geometric triangulation solution for big BIM data. Section 5 describes the empirical studies, and the last section presents conclusions. 2. Related work 2.1. Building information model/modeling AECO/FM industries have already captured extensive profits from BIM. Moreover, the use of BIM is also beneficial for many other areas, e.g., smart city systems. Currently, BIM has attracted extensive attention from both research and industry. Because IFC is the de facto standard of BIM, most current studies on BIM are built on top of IFC. Current studies on BIM can be summarized as follows.

(1) A huge amount of memory is required to triangulate BIM data. According to the performance statistics of a BIMserver [17], which is a widely used platform for building BIM applications, even a 25GB memory fails to parse a 3.7 GByte IFC file. As a result, a computer with 220 GB memory has been used in some studies [17]. Undoubtedly, it is impossible to equip such a supercomputer for every construction project. This triggers new demand to triangulate BIM file in ordinary computers. (2) A very long time is required for BIM data triangulation. As shown by the empirical study results in Section 5.2, more than an hour is required to triangulate a 300 MB IFC file. Moreover, the larger the IFC file, the more time the parsing engine requires. The triangulation speed is an important factor in scenarios where project members need to make the conversion more frequently and efficiently. Online BIM service is another scenario where fast generation of the triangulated geometries is usually desired. Every day, hundreds of BIM files are uploaded and processed. On one hand, online BIM platform has to compute the uploaded BIM files duly so that latter uploaded BIM files can be processed timely. On the other hand, efficiency is one of the crucial indices for online user experience [18]. Once upload a BIM file, online users always anticipate to review and process the BIM data in the next few minutes.

(1) BIM data processing. BIM aims to enable data interoperability among all the participants during the life cycle of a building. Therefore, many studies have explored the data processing issues of BIM. For example, Lin et al. [8] proposed a BIM retrieval method based on natural language processing (NLP); Belsky et al. [20] proposed a solution to enrich the semantics of the objects in BIM; Ladenhauf et al. [21] investigated how to extract data from BIM for energy analysis; and Beach et al. [22] presented a data management model over the cloud. The data processing empowers BIM applications. The present study falls into this category because it processes IFC data to highlight the BIM application. (2) Application of BIM. In applications, BIM intends to enable collaboration among the participants. Oh et al. [5] developed a system for design collaboration. Fu et al. [23] developed a visualization system for n dimensions (nD) based on IFC. Motamedi et al. [24] investigated a facility management system jointly using BIM and RFID. Zhou et al. [25] proposed an algorithm to extract the outer surfaces of BIM models for integration with geographic information systems. Surely, the 3D visualization system is also one of the most fundamental areas for collaboration, as well as the applications mentioned above. This study proposes a scalable 3D geometry triangulation algorithm that can enhance the 3D visualization system [16].

These two processability issues in BIM triangulation hinder BIM applications to some extent. Many factors, e.g., triangulation resolution, algorithm design and implementation, may contribute to the large memory usage or/and longstanding consumption in BIM triangulation. Accordingly, both lowering the triangulation resolution and optimizing the triangulation algorithm and its implementation can mitigate these two processability issues. This study reduces the memory usage and accelerates the time consumption of BIM triangulation without changing the triangulation resolution from another perspective by splitting and triangulating the original BIM file using parallel computing framework. Obviously, our scheme is not exclusive but complementary for the current efforts. It can be applied jointly with any BIM triangulation tools for more suitable triangulation solutions in specific environments.

2.2. IFC geometric triangulation and WebGL-based visualization BIM visualization is necessary for almost all BIM systems. The triangular mesh is widely accepted as the 3D shape data model, and triangles are a simple geometric shape that can be rendered directly in most software (especially 3D viewers). In the era of Internet and mobile Internet, building Web or mobile applications will bring in more profits in addition to the BIM systems. Because only triangle meshes are supported in WebGL, transforming IFC to triangles is the first and primary 2

Automation in Construction 107 (2019) 102942

X. Zhou, et al.

task. Although many general purpose libraries in the Computer Graphics communities [26] can effectively address the problem of triangulation of surfaces, they cannot be directly applied to triangulate BIM data. Because the geometric data in BIM data is usually expressed in several 3D models, including the Brep, the NURBS, the CSG, and the SweptSolid. Some acceptable efforts [15,16,27] have been made in Web-based BIM visualization systems. For instance, BIMServer [27] uses IfcOpenShell [14] to transform 3D shapes from IFC into triangles and renders the results in BIM Surfer [28] or BIMviews [29] using WebGL. Liu et al. [15] also proposed a Web3D tool by converting IFC file into .obj format and visualizing the .obj data using Flash3D. Recently, Zhou et al. [16] proposed a WebGL-based online visualization system, termed WebBIM. WebBIM converts IFC files into lightweight triangular meshes and enables BIM visualization in any device equipped with a WebGL-supported browser. However, the triangulation process becomes the bottleneck in both efficiency and scalability when deploying WebBIM as an online service. The end-users have to wait quite a long time for the triangulation process to visualize BIM files. What's even worse, the triangulation process may fail due to the limited hardware resources when computing big BIM data. Some triangulation solutions like Geometry Kernel1 mitigate this issue by lowering the triangulation resolution. However, the lower triangulation resolution may present a lower quality of the BIM visualization. Fig. 1 presents an example of an IfcFlowSegment object. Fig. 1(a) and (b) are the visualization results of triangular meshes generated by WebBIM [16] and IFC WebGL tool2 using Geometry Kernel, respectively. The IfcFlowSegment object remains as a cylinder in high resolution but an octagon column in low resolution. Different from the efforts on lowering the resolution, this study addresses the aforementioned issue using parallel computing framework and retains the resolution. Some studies have also noticed the importance of maximizing enduser experience when visualizing 3D data using web browsers. To deliver adaptive, secure, and scalable user-centric data visualization, Max et al. [30] proposed a streamable format for generalized Web-based 3D data transmission called a Shape Resource Container (SRC). SRC is optimized for progressive, Web-based transmission of 3D mesh data with a minimum number of HTTP requests. On top of SRC, Johannes et al. [31] proposed the webVis/instant3DHub, providing visual computing as a service infrastructure. In applications like plant lifecycle management, webVis/instant3DHub firstly triangulates CAD data (e.g., RVM) into ISO standards (e.g., X3D). Then, an adaptive and automated combination of client, server and hybrid visualization techniques are utilized to enable real-time rendering of massive data sets like X3D using WebGL. Obviously, webVis/instant3DHub mainly focuses on the real-time rendering of 3D mesh data, while this study aims to present an efficient triangulation scheme for BIM data with limited memory. Obviously, jointly using webVis/instant3DHub and an efficient triangulation tool can provide a more powerful online BIM visualization service.

Specifically, IFC defines an EXPRESS-based entity-relationship model consisting of several hundred entities organized into an objectbased inheritance hierarchy. At the most abstract level, IFC divides all entities into rooted and non-rooted entities. Rooted entities derive from IfcRoot and have a concept of identity (having a GUID), along with attributes for name, description, and revision control. Non-rooted entities do not have an identity, and instances exist only if referenced from a rooted instance directly or indirectly. IfcRoot is subdivided into three abstract concepts: object definitions, relationships, and property sets:

• IfcObjectDefinition captures tangible object occurrences and types; • IfcRelationship captures relationships among objects; • IfcPropertyDefinition captures dynamically extensible properties about objects.

Undoubtedly, much effort is required in advance to obtain knowledge of hundreds of entities and tens of relationships among entities in IFC when applying BIM to decision support systems. Consequently, converting IFC to a more comprehensible format for developers can dramatically smooth the application of BIM. 3.2. Geometric definition in IFC Because this study aims to present an efficient online geometry triangulation service for BIM, the related terminologies are systematically defined in this subsection. 3.2.1. Definition 1 (IFC instance/BIM instance) An IFC instance i is a concrete instance of an IFC entity. Take Fig. 2 as an example. IfcWallStandardCase is an IFC entity, whereas #155, represented by i155, is an IFC instance of IfcWallStandardCase. 3.2.2. Definition 2 (geometric object) The term geometric object refers to an IFC instance that relates to a geometric or spatial context. Usually, a geometric object o has a shape representation s and an object placement l. Hence, a geometric object can be modeled by a tuple, o = (s, l). Take Fig. 2 as an instance. The wall described by IFC instance #155 has a 3D shape and a specific placement. It is a geometric object represented as o155. In this study, M denotes the set of all geometric objects in an IFC file. Obviously, M is a subset of all the IFC instances in an IFC file. In IFC, all geometric objects are defined by the entities inherited from IfcProduct. Apparently, a geometric object is a facility with a 3D shape and a specific placement in a building, whereas an IFC instance is described by a line in an IFC file. This means that a geometric object is described by several IFC instances. Fig. 3 presents a concrete example. Each line in Fig. 3(a) presents an IFC instance. Totally, the IFC file has 96 IFC instances. However, the IFC file has only one geometric object o45, which is a wall object. When visualizing the IFC file, only the geometric object o45 is showed with 3D shape.

3. Preliminary knowledge

3.2.3. Definition 3 (shape representation) The shape representation s of a geometric object refers to the representation of the geometric object that is defined by multiple shape properties (including colors) within the same object coordinate system. Specifically, the shape representation of an IfcProduct is described either by a representation (IfcProductRepresentation) or as a special case of a shape representation (IfcProductDefinitionShape). Take Fig. 3 as an example. s51 is the shape representation of o45 and is expressed by IfcProductDefinitionShape.

3.1. Industrial foundation classes (IFC) IFC is a platform-neutral, open file format specification that was originally intended to describe building and construction industry data. IFC is object-based and usually exists as files with file extension *.ifc. As an open standard, IFC is an official international standard, ISO 16739:2013. Because IFC is open and available, it has been widely used as a collaboration format in BIM-based projects, facilitating interoperability in AECO/FM industries. Due to the ease of interoperability between software platforms, many official organizations have also adopted IFC. 1 2

3.2.4. Definition 4 (object placement) An object placement l is the placement or location of a geometric object in space. l can be relative to either the world coordinate system, or to the object placement of another product, or to a constraint, e.g., grid axes. Both shape representation and object placement are defined by

http://rdf.bg/product-list/geometry-kernel/. http://rdf.bg/product-list/ifc-engine/ifc-webgl/. 3

Automation in Construction 107 (2019) 102942

X. Zhou, et al.

Fig. 1. Comparison of high and low triangulation resolutions.

instance. The second parameter, “#41”, refers to an IfcOwnerHistory instance. “Wall xyz” is the name of the wall object, followed by its description. “#124” refers to an IfcLocalPlacement instance that defines the object coordinate system of the wall. “#151” is an IfcProductDefinitionShape instance defining the shape representation of the wall. IFC instances #155, #124, and #151 together define the geometric object o155, which is a wall. Fig. 1 intuitively presents their relationships. 3.3. Overall framework Parallel computing frameworks, e.g., MapReduce [32], Spark [33], and Message Process Interface (MPI) [34], are powerful tools to tackle intensive Big Data computation efficiently in a scalable manner using lowend computers. They have been widely used to address Big Data processing in various areas [35]. Obviously, using a parallel computing framework can enhance the processability of big BIM geometric triangulation. With this assumption, this study aims to address the memory explosion problem and the computing efficiency problem in terms of the processability of big BIM data in traditional BIM parsing tools and presents an online BIM triangulation service (BIMTriSer) by introducing a parallel computing framework. However, the complex relationships among IFC instances prevent the direct use of this parallel computing framework in triangulating BIM data. Hence, splitting the big BIM data (or IFC file) into small independent IFC files is necessary. Fig. 5 presents the overall framework of BIMTriSer. BIMTriSer receives the IFC files through a REST API [36]. To use the power of the parallel computing framework, BIMTriSer uses IFCSplitter to split the IFC file into several small independent IFC files that can be triangulated in only a few seconds with limited memory usage. Then BIMTriSer dispatches the small IFC files into different IFC triangulation workstations using a parallel computing framework. Each IFC triangulation unit reads the geometry of the objects in the small IFC file and converts the shape representations to triangular meshes. All the triangular meshes are stored in a database for retrieval by decision support systems. With enough IFC triangulation workstations, BIMTriSer can perform geometric triangulation of IFC files of any size efficiently using limited memory. Apparently, BIMTriSer solves the processability problem for big BIM data, thus providing a powerful tool for BIM applications and empowering current building-related decision support systems.

Fig. 2. An example of a geometric description in an IFC file. (a) IFC instance. The IFC file has totally 96 IFC instances and one geometric object o45. (b) Visualization of IFC. The IFC has only one geometric object o45.

several IFC instances. In an IFC specification, object placement is defined by IfcObjectPlacement, and the axis placement information in IfcObjectPlacement determines the transformation for the object coordinate system. Take Fig. 3 as an example. l46 is the object placement of o45 and is expressed by IfcLocalPlacement, which Inherits from IfcObjectPlacement. Any object with a geometric or spatial context can be described by IfcProduct. When an IfcProduct has a geometric representation, a specific location is assigned. Fig. 4 shows the geometric expression of IfcProduct in Express-G. Obviously, an IfcProduct optionally has a 0 or 1 representation and location. When an IfcProduct object is assigned a geometric representation, the specific location should also be given. The representation of IfcProduct is described in IfcProductRepresentation. The coordinate system of all points and directions in IfcProductRepresentation is defined by IfcObjectPlacement. The following is a full example of an IFC instance, geometric object, shape representation, and object placement.

4. Online BIM triangulation service

Example 1. (IFCWallStandardCase) #155 = IFCWALLSTANDARDCASE(‘3vB2YO$MX4xv5uCqZZG05x’, #41, ‘Wall xyz’, ‘Description of Wall’, $, #124, #151, ‘308537’); “#155” is the line number of the IfcWallStandardCase and represents an IFC instance of IfcWallStandardCase. The internal member is initialized by the brackets of eight parameters separated by commas. The “3vB2YO$MX4xv5uCqZZG05x” is the GUID of the IfcWallStandardCase

4.1. IFCSplitter IFCSplitter deconstructs the IFC file into small independent IFC files that can be assigned to and computed in different IFC triangulation units separately. In this manner, the geometry of a large-scale IFC file can be converted into triangular meshes more efficiently with limited 4

Automation in Construction 107 (2019) 102942

X. Zhou, et al.

Fig. 3. Example of IFC instance and geometric object.

As discussed above, a geometric object o is composed by its shape representation s and its object placement l. In fact, the only difference between geometric objects sharing the same shape representation is the object placement, which can be processed easily. Hence, it is desirable that all geometric objects with the same shape representation should be described in the same small IFC file. In this scenario, only one pass is required when triangulating geometric objects with the same shape representation. This can greatly reduce total triangulation time. IFCSplitter is built on top of this basic principle. IFC is an entity-relationship model, and IfcRelationship describes relationships among objects. IFCSplitter first models the reference relationship as a graph. For a string describing an IFC instance, i.e. i155 in Example 1, IFCSplitter parses the string from left to right character by character. An IFC instance starts with ‘#’ and ends with ‘=’, following with the IFC type. Thus, IFC instance i155 typing IFCWallStandardCase is obtained. Then, the bracketed text next to the IFC type expresses the content of the IFC instance. Once a character ‘#’ is detected outside a pair of single quotes in the content text, the following characters before punctuation are read. If these characters form a number, then an IFC instance is detected. For instance, when the first ‘#’ after ‘(’ is read, text ‘41’ is read to check whether it is a number or not. Since ‘41’ is a number, i41 is identified. In this scenario, node i41 and edge (i155, i41) are added to G. Following this way, i124 and i151, which define the object placement and the 3D shape representation of i155 respectively, are recognized. Therefore, two edges from i155 to il24 and to i151 are constructed. Similarly, i151 further links to the IFC instances cited by i151. Finally, a directed graph G capturing the reference relationships of

Fig. 4. Geometric expression of IFCProduct in Express-G.

memory usage. This subsection symmetrically presents the basic principles of IFCSplitter and develops the IFCSplitter algorithm. The direct way to split an IFC file is to separate geometric objects into different small IFC files according to the IFC specification. This solution starts with an IFCProduct instance and then scans all the IFC instances to aggregate the shape representation and object placement of the IFCProduct. However, many geometric objects may share the same shape representation in actual BIM data. If every geometric object exists in a separate IFC file, then those shape representations that are shared by many geometric objects have to be parsed several times. As a result, the processing cost of geometric triangulation becomes much greater. Take Fig. 6 as an example. Twenty-three windows share the same shape representations. If the geometries of the 23 windows are split into 23 different small IFC files for further triangulation, the same shape representation must be completely parsed 23 times. 5

Automation in Construction 107 (2019) 102942

X. Zhou, et al.

BIMTriSer REST API

IFCSplitter Split original IFC file into several independent small IFC files

IFC Triangulation Unit

IFC Triangulation Unit

IFC Triangulation Unit

IFC Triangulation Unit

Parallel Computing Framework

Small IFC files

IFC file

REST API

Triangular Mesh Database

Decision Support Systems

Fig. 5. Overall framework of BIMTriSer.

the geometric objects can be constructed. Fig. 7(a) presents a full example of the reference relationship of a window object. o124 is a window object, referring to i125 and i130. The left of Fig. 7(a) presents the reference relationship of l124, while the right is the reference relationship of s130. l124 refers to i98 and i126, i98 points to i46 and i99, and i126 cites i127, i128, and i129. Since i127, i128 and i129 don't refer to any other IFC instances, they are the leaf IFC instances. Both i46 and i99 are not leafed IFC instances, the IFC instances they refer to are added. Following this way, a tree-like reference graph of l125 is constructed and shows on the left of Fig. 7(b). Similarly, the reference graph of s130 is obtained as the right of Fig. 7(b). When putting all the IFC instances

× 23

×7

Fig. 6. Illustration of shape representation reused. (a) Reference relationship of geometric object o124. (b) Directed reference graph of geometric object o124.

Fig. 7. Example of reference relationship in IFC. 6

Automation in Construction 107 (2019) 102942

X. Zhou, et al.

related to o124 into a single IFC file, the IFC file can be triangulated separately. The bottom right of Fig. 7(a) shows the visualization of o124. Fig. 7(b) presents the directed reference graph of o124. All the reference relationships in an IFC file generates the directed reference graph G. With G, IFCSplitter starts from the shape representation instances, but not the IFCProduct instances. The parent nodes of a shape representation, or the nodes linking to a shape representation node, are the geometric objects represented by IFCProduct. Undoubtedly, a shape representation node in G may have more than one parent geometric object node. Because these geometric object nodes share the same shape representation, their geometric object definitions are written into the same IFC file. Fig. 8 presents an illustration. o1 and o2 share the same shape representation s1. o1, o2, s1, l1, l2, and all the shape definition objects for s1 are separated into an IFC file, where l1 and l2 are the object placement definitions of o1 and o2. Similarly, o3, l3, s2, and the definition objects for s2 are output to another IFC file. In this way, IFCSplitter deconstructs the original large IFC file into small independent IFC files. Because each small independent IFC file can describe the 3D shape representation of the geometric objects sharing the same shape representation, they can be parsed correctly and efficiently using limited memory. Fig. 9 presents a concrete example of small independent IFC file generated by IFCSplitter. o124 and o242 are two window objects, sharing the same shape representation s130. Thus, all the IFC instances related to o124 and o242 are written into the same IFC file, which can be triangulated and rendered separately. The bottom left of Fig. 9 shows the two geometric objects. Obviously, they have the same 3D shape but different object placements.

linking to s and their object placements costs O(|Ms|) in time. It can easily be determined that generating the IFC sub-file relating to s costs O(|Ms|) + O(|s|) = O(|Ms| + |s|), where |s| represents the number of IFC instances describing s. Thus, generating all the IFC sub-files according to G costs ∑s[O(| Ms| ) + O(| s| )] = O(∑s(| Ms| + | s| )). Summing up, the time complexity of Algorithm 1 is O(m) + O(∑s(| Ms| + | s| )). Note that O(∑s(| Ms| + | s| )) expresses the number of IFC instances describing all the geometric objects. As a result, both the number of IFC instances and the number of IFC instances describing all the geometric objects contribute to the running time of IFCSplitter. Apparently, IFCSplitter has to de-serialize the original IFC file and serialize the small independent IFC sub-files. The IFC file serialization reads and parses the IFC file from external memory, while the de-serialization formats and writes IFC files to external memory. The running time of reading and writing files involve both hardware and software environments, e.g., CPU, external memory, computer bus, and operating system. For instance, high-performance CPU, external memory and computer bus can accelerate reading files from external memory to internal memory, as well as writing files from internal memory to external memory. Therefore, we only discuss the time complexity of parsing IFC texts in internal memory to G and formatting G to IFC texts. Lines 22–32 in Algorithm 1 describe the serialization process of an IFC instance in string format. Obviously, only one round scanning of characters is enough for the construction of G. Subsequently, the time complexity of serialization of an IFC instance i cost O(Ni), where Ni is the number of characters describing i. Since a dictionary is employed to store mappings from IFC instances to their texts, the text of an IFC instance can be obtained effortlessly from the dictionary during the de-serialization process. That is, the time complexity of de-serialization of an IFC instance i costs O(1).

Algorithm 1. IFCSplitter – split one large IFC file into small independent IFC files. It is noticing that basic information is also essential in triangulating each small IFC file. Firstly, each IFC file should contain an IFC header section, which defines the IFC schema it uses. Secondly, each IFC file should inherit the IfcProject instance from the original IFC file. Because the IfcProject instance defines the overall context, including default units, geometric representation context for the shape representations, global positioning of the project coordinate system and some other basic information. With the same IfcProject instance, the triangular meshes computed from each IFC file can be mapped back to the same global coordinates. Thirdly, each IFC file should be formatted according to the IFC schema it uses. Algorithm 1 summarizes the whole process carried out by the IFCSplitter. Line 2 constructs the reference relationship directed graph G according to the IFC specification. Lines 3–13 iterate each shape representation and write the geometric objects sharing the same shape representation into the same IFC file. Specifically, line 5 retrieves the geometric objects, lines 6–9 collect the object placement definition objects of these geometric objects, lines 11–12 retrieve the definitions of the shape representation, and line 13 writes the collected IFC instances into the IFC file. In Algorithm 1, the construction of G requires one scan of all m IFC instances in the IFC file, costing O(m) in time complexity. For a given shape representation s, collecting all the geometric object nodes Ms

l1

l2

o1

o2

To scale the geometric triangulation, BIMTriSer uses a parallel computing framework. This framework is composed of server IFC triangulation units. Each IFC triangulation unit receives the small IFC files deconstructed by the IFCSplitter, triangulates the geometry, and stores the triangular meshes into the database. 4.2.1. IFC triangulation unit The main task of an IFC triangulation unit is to convert the original geometric description in the IFC into triangular meshes. In the IFC specification, the 3D shape of a facility is usually described by solid models, including Brep, SweptSolid, and CSG. SweptSolid is a standard geometric representation in which a profile or area is extruded along or revolved around an axis. The CSG model is defined as a collection of primitive solids that are combined using certain operations. Both CSG and SweptSolid are advanced geometric representations with enhanced profile types, whereas Brep is the foundational schema used in most object-based 3D models. Because Brep takes the vertex and the curve as its basic geometric shapes, it can be converted into triangular mesh surfaces effortlessly. Subsequently, the IFC triangulation unit first transforms SweptSolid and CSG into Brep [37]. After unifying the solid model as Brep, the IFC triangulation unit computes Delaunay's triangulation using Watson's algorithm [38]. Basically, Delaunay's triangulation with Watson's algorithm is an incremental algorithm that splits triangles until the resulting triangulation satisfies certain deflection criteria. The algorithm includes two major options to define triangulation: linear and angular deflections. In the first step, all edges from a face are discretized according to the specified parameters. In the second step, the faces are tessellated. Linear deflection limits the distance between a curve and its tessellation, whereas angular deflection limits the angle between subsequent segments in a polyline. More details about the IFC triangulation process in IFC triangulation unit can refer to [16]. Zhou et al. [16] also demonstrated the ability to visualize BIM triangular mesh data in different devices using WebGL.

l3 o3

s1

s2

Other Shape Objects

Other Shape Objects

IFC file 1

4.2. Geometric triangulation of BIM

IFC file 2

Fig. 8. Small independent IFC files generated by IFCSplitter. 7

Automation in Construction 107 (2019) 102942

X. Zhou, et al.

Fig. 9. An example of a small independent IFC file.

Algorithm 2. BIMTriSer – triangulating IFC file in parallel. Request BIMTriSer

4.2.2. Scaling the IFC triangulation unit To scale to very large IFC files, this study used the approach of distributing the split independent small IFC files onto multiple machines in a computer cluster and performing IFC triangulation using all the machines in parallel. The data were distributed sequentially to the machines. Once a machine was available after finishing the parsing of its assigned small IFC file, a new small IFC file was assigned. When all the small IFC files generated by the IFCSplitter were computed, the original IFC file was totally parsed. Approximately, each machine was assigned Ns/Nm IFC files, where Ns and Nm are the numbers of 3D shape representations in the original IFC file and the number of machines in the computing cluster respectively. To distribute the IFC triangulation process on a computer cluster, BIMTriSer implemented a Map-Reduce-like algorithm using the message-passing interface (MPI) specification [34]. The BIMTriSer request is usually sent from a client to one of the computers in the MPI cluster, which is called here the master server (see Fig. 10). The master server broadcasts the IFC triangulation request to all processes in the cluster, after which each process can run the IFC triangulation algorithm in parallel. When all the small separate IFC files have been parsed, the result is returned to the client. Because each machine writes the triangular mesh data directly to the database, no MPI reduction is required. In other words, no merge operation is needed in the whole process. Algorithm 2 summarizes the main process of BIMTriSer. First, the large IFC file is split by the IFCSplitter in line 2. Then line 3 broadcasts the triangulation command to all the machines in the cluster. Lines 4–8 triangulate the small independent IFC files and write the triangular meshes to the database. As aforementioned, many BIM triangulation algorithms and tools existed. Although this study employs the one proposed in [16], it is effortless to embed other algorithms or tools in parallel computing framework on top of IFCSplitter. Compared to existing tools triangulating original BIM file in a single thread, it is our belief that our parallel scheme, equipped with the same triangulation tool, can compute the triangular meshes using less memory in a shorter time while retaining the triangulation resolution.

Write the split small IFC files

Master Server Read small IFC file

Distributed File System MPI Broadcast

Client

Client Server

Write triangular meshes

Database Client Server Fig. 10. Scaling IFC triangulation on a computer cluster using the message passing interface standard.

IfcOpenShell to triangulate the BIM geometric data in high resolution, was used as the baseline for BIMTriSer. 5.1.2. Evaluation index BIMTriSer aims to improve the processability of big BIM triangulation by introducing a parallel computing framework. Because computing resources and efficiency are two crucial factors in measuring processability, memory usage and running time were chosen as the two evaluation indices in these experiments. 5.1.3. Datasets Experiments were conducted on nine IFC files with sizes from 9.5 M to 881.5 M. Table 1 presents the statistics of the nine IFC files. The numbers of geometric objects varied from 735 to 39,645. Evidently, the size of the IFC file is not linear with the number of geometric objects. Two possible factors may contribute to this fact. First, the greater the number of geometric objects that share the same 3D shape representation, the smaller the IFC file will be. Second, some geometric objects may have a much more complex 3D shape, which requires many more IFC instances to describe the 3D shape. Fig. 11 presents the 3D shapes of the nine IFC files.

5. Empirical studies 5.1. Experimental settings

5.1.4. Experimental setting All the experiments were conducted on a computer with a 2.6 GHz CPU and 12 GB memory. Moreover, BIMTriSer3 executes 10 separate processes after the original IFC file has been split.

5.1.1. Baseline Currently, there is still no solution that scales the big IFC file triangulation problem in parallel. The conventional IFC triangulation solution triangulates the large IFC file in a single computer. The wellknown BIM platforms [14–17,27] perform in this manner. Without loss of generality, BIMServer [27], a widely used BIM platform using

3 Currently, BIMTriSer has been deployed as an online service at https:// www.bos.xyz.

8

Automation in Construction 107 (2019) 102942

X. Zhou, et al.

Table 1 Statistics of the IFC files. #

Size (M)

# of IFC instances

# of geometric objects

Description for the IFC

1 2 3 4 5 6 7 8 9

9.5 50.8 58.9 86.8 102.1 181.2 247.5 365.0 881.5

117,753 958,373 707,375 1,694,945 1,952,876 2,746,559 3,154,936 6,416,162 15,348,214

1706 735 11,255 1334 3650 39,645 38,962 17,747 3593

MEP model MEP model with basic architecture MEP model of a big building House model with all disciplines Building model with all disciplines Architectural model of a big building MEP model of a big building MEP model of a big building Synthetic model

5.2. Empirical results

parse even the 241.7 Mbyte IFC file. This long-time consumption may create a frustrating user experience, especially for online applications. On the contrary, BIMTriSer greatly reduced parsing time. In the present experiments, the IFC file with 365.0 Mbytes required the longest triangulation time, 1243.8 s. The triangulation time for the 881.5 Mbyte IFC file was 841.36 s, which was much less than that of the 365.0 Mbyte file. This occurred because the 365.0 Mbyte IFC file had many more geometric objects than the 881.5 Mbyte IFC file. Evidently, BIMTriSer could triangulate the IFC file much more efficiently than BIMServer. In the empirical studies, the running times of BIMServer were 8.0 to 18.3 times those of BIMTriSer. Concretely, BIMTriSer required 12.5% of the time of BIMServer in the 50.8 MByte IFC file triangulation and only 5.5% of the time for the 58.9 Mbyte IFC file. It is clear that BIMTriSer can solve the efficiency problem of processability for big BIMs. It was also verified that IFCSplitter required limited time for the whole triangulation process. As demonstrated in Table 2, IFCSplitter

Fig. 12 presents a memory usage comparison between BIMServer and BIMTriSer for the nine IFC files. Apparently, the larger the IFC file, the more memory BIMServer requires. The maximum memory usage for the 241.7 Mbyte IFC file was 8.3 Gbytes of memory in BIMServer. Because even 12 Gbytes of memory could not parse the 356.4 Mbyte and 881.5 Mbyte IFC files in 1 h, the memory usages of the 356.4 Mbyte and 881.5Mbyte IFC files are not presented in Fig. 7. Note that the memory usage in BIMTriSer is stable and requires no > 1 Gbyte. Hence, a computer equipped with 4 Gbytes memory can run several IFC geometric triangulation processes to improve efficiency. Thus, BIMTriSer solves the memory usage problem in traditional BIM geometric triangulation tools. Fig. 13 gives the running times of BIMServer and BIMTriSer for the nine IFC files. Obviously, the running time in BIMServer increased dramatically with the size of the IFC file. Almost 1 h was required to

Fig. 11. 3D shapes of the nine IFC files used in the experiments. 9

Automation in Construction 107 (2019) 102942

X. Zhou, et al.

Table 2 Running time of IFCSplitter.

Fig. 12. Memory usage comparison between BIMserver and BIMTriSer.

#

Size (M)

Running Time of IFCSplitter (s)

Percentage in BIMTriSer (%)

1 2 3 4 5 6 7 8 9

9.5 50.8 58.9 86.8 102.1 181.2 247.5 365.0 881.5

0.54 10.55 4.56 51.28 26.26 17.51 20.22 110.26 69.02

3.82 16.96 10.9 32.55 24.97 5.85 8.25 8.87 8.2

The bold are the maximal value in the columns.

As discussed above, when more computers and more processes are provided for BIMTriSer, such large IFC files can be parsed in much less time. Consequently, BIMTriSer solves the parsing time problem in traditional triangulation algorithms and enables a user-friendly experience in online BIM systems. Although the performance of BIMTriSer has been verified for only nine IFC files, it is anticipated that BIMTriSer would have similar performances with more IFC files. 6. Conclusions This study proposed a novel scalable BIM triangulation service, called BIMTriSer, to improve the processability of big BIM data. First, this study systematically analyzed the compositions of the geometric objects in IFC files. On top of this, BIMTriSer constructs a reference relationship graph and splits the original IFC file into several independent small IFC files. Then BIMTriSer uses the parallel computing framework to enable scaling of IFC geometric triangulation. Experiments showed that BIMTriSer can perform much more efficiently using limited memory than traditional solutions. Although the proposed BIMTriSer is built on top of MPI, it can be converted to other parallel computing frameworks such as MapReduce [32] and Spark [33]. Since BIMTriSer splits original BIM file into several small independent BIM files, it can also be upgraded using containerization technologies and technologies for distribution and load-balancing on the cloud [39] to build a more powerful online BIM triangulation service. The innovation of our study is that we presented algorithms to enable online geometry triangulation for BIM Big Data using a parallel computing framework. Firstly, we proposed a novel IFC geometry splitting method according to the IFC specification, called IFCSplitter. To parse the geometries of facilities in parallel, splitting an IFC file into small independent, yet geometry-reserved IFC files plays a crucial role. IFCSplitter constructs a reference relationship graph according to the IFC specification and splits IFC files using the power of the graph. Secondly, we developed an online geometric triangulation service for BIM, called BIMTriSer. BIMTriSer uses the proposed IFCSplitter to split

Fig. 13. Running time comparison between BIMserver and BIMTriSer.

costs < 10% of the total running time of BIMTriSer in five out of nine BIM files. The running time of IFCSplitter was 110.26 s for the 365.0 MByte BIM file, which was the maximum among all nine BIM files. However, it accounted for only 8.87% of running time in BIMTriSer. Two reasons can explain this finding. First, the 365.0 Mbyte BIM file was much larger than the other BIM files except for the 881.5 Mbyte BIM file, resulting in many more IFC instances. Second, the 365.0 Mbyte BIM file had many more geometric objects, and also many more IFC instances describing geometric objects, than the 881.5 Mbyte BIM file. This is consistent with the theoretical analysis. Moreover, the running times of IFCSplitter occupied only small portions of the total running time in BIMTriSer. IFCSplitter costs 51.28 s for the 86.8 Mbyte BIM file, which was 32.55% of running times in BIMTriSer. This percentage was the maximum among all nine experimental BIM files. IFCSplitter is a critical process in BIMTriSer, which enables BIM geometric triangulation in parallel. BIMTriSer speeds up the triangulation process by > 5 times on top of IFCSplitter and parallel computing in the 86.8 Mbyte BIM file. Admittedly, BIMTriSer required some time to divide a BIM file into several sub-files in IFCSplitter before carrying out the geometric triangulation. However, our empirical studies showed that IFCSplitter works efficiently and occupies only a small portion of the whole geometric triangulation process. Because BIMTriSer addresses the processability problem by introducing a parallel computing framework, the performance of BIMTriSer was examined in a single computer with different numbers of processes. Fig. 14 presents the results of an experiment in which BIMTriSer was executed with multiple MPI processes on a single computer. Clearly, the overall geometric triangulation time decreased when the number of processes increased from 2 to 10 by 2. However, the performance of BIMTriSer stayed almost the same when the number of processes was greater than six. This occurred because all the CPUs were 100% utilized when more than six geometric triangulation processes were running at the same time. In this scenario, the authors suggest that more computers should be added to the parallel computing cluster to enable faster BIM triangulation. Because memory was not the bottleneck in the present experiments, the memory usage with different numbers of processes in a single computer was not shown.

Fig. 14. Running time comparison with different numbers of processes in BIMTriSer. 10

Automation in Construction 107 (2019) 102942

X. Zhou, et al.

the original IFC file into small independent IFC files and employs a parallel computing framework to scale the IFC triangulation. Because BIMTriSer distributes the BIM geometric triangulation into different processes, it significantly decreases triangulation time and lowers the memory requirement. Finally, we demonstrated the performance of BIMTriSer. The empirical results in the geometry triangulation task showed that the adoption of parallel computing can dramatically improve the processability of BIM Big Data. Although IFCSplitter was applied in BIM geometric data triangulation, it also envisages the parallelized semantic analysis.

[16] X. Zhou, J. Wang, M. Guo, Z. Gao, Cross-platform online visualization system for open BIM based on WebGL, Multimedia Tools and Applications, 2018, pp. 1–16, , https://doi.org/10.1007/s11042-018-5820-0. [17] GitHub, “BIMserver Performance Statistics,” BIMserver, [online]Available: https:// github.com/opensourceBIM/BIMserver/wiki/Performance-statistics (Last accessed: 11/5/2018). [18] M. Bilal, L.O. Oyedele, J. Qadir, K. Munir, S.O. Ajayi, O.O. Akinade, H.A. Owolabi, H.A. Alaka, M. Pasha, Big data in the construction industry: a review of present status, opportunities, and future trends, Adv. Eng. Inform. 30 (3) (2016) 500–521, https://doi.org/10.1016/j.aei.2016.07.001. [19] P. Brooks, B. Hestnes, User measures of quality of experience: why being objective and quantitative is important, IEEE Netw. 24 (2) (2010) 8–13, https://doi.org/10. 1109/MNET.2010.5430138. [20] M. Belsky, R. Sacks, I. Brilakis, Semantic enrichment for building information modeling, Computer-Aided Civil and Infrastructure Engineering 31 (4) (2016) 261–274, https://doi.org/10.1111/mice.12128. [21] D. Ladenhauf, K. Battisti, R. Berndt, E. Eggeling, D.W. Fellner, M.G. Michlmair, T. Ullrich, Computational geometry in the context of building information modeling, Energy and buildings 115 (2016) 78–84, https://doi.org/10.1016/j.enbuild. 2015.02.056. [22] T. Beach, O. Rana, Y. Rezgui, M. Parashar, Governance model for cloud computing in building information management, IEEE Trans. Serv. Comput. 8 (2) (2015) 314–327, https://doi.org/10.1109/TSC.2013.50. [23] C. Fu, G. Aouad, A. Lee, A.M. Ponting, S. Wu, IFC model viewer to support nD model application, Autom. Constr. 15 (2) (2006) 178–185, https://doi.org/10.1016/j. autcon.2005.04.002. [24] A. Motamedi, M.M. Soltani, S. Setayeshgar, A. Hammad, Extending IFC to incorporate information of RFID tags attached to building elements, Adv. Eng. Inform. 30 (1) (2016) 39–53, https://doi.org/10.1016/j.aei.2015.11.004. [25] X. Zhou, J. Zhao, J. Wang, D. Su, H. Zhang, M. Guo, Z. Li, OutDet: an algorithm for extracting the outer surfaces of building information models for integration with geographic information systems, Int. J. Geogr. Inf. Sci. 33 (7) (2019) 1444–1470, https://doi.org/10.1080/13658816.2019.1572894. [26] B. Marussig, T.J. Hughes, A review of trimming in isogeometric analysis: challenges, data exchange and simulation aspects, Archives of computational methods in engineering 25 (4) (2018) 1059–1127, https://doi.org/10.1007/s11831-0179220-9. [27] J. Beetz, L. van Berlo, R. de Laat, P. van den Helm, BIMserver. org–an open source IFC model server, Proceedings of the CIB W78 Conference, 2010 http://www. bimserver.org/wp-content/uploads/sites/6/2010/11/Beetz_Berlo-CIB-W78_Cairo. pdf. [28] BIM Surfer, [online]Available: http://bimsurfer.org(Lastaccessed: 11/5/2018). [29] BIM views, [online]Available: http://www.bimview.fr (Last accessed: 11/5/2018). [30] M. Limper, M. Thöner, J. Behr, D.W. Fellner, SRC-a streamable format for generalized web-based 3D data transmission, Proceedings of the 19th International ACM Conference on 3D Web Technologies, ACM, 2014, pp. 35–43, , https://doi. org/10.1145/2628588.2628589. [31] J. Behr, C. Mouton, S. Parfouru, J. Champeau, C. Jeulin, M. Thöner, C. Stein, M. Schmitt, M. Limper, M. de Sousa, T.A. Franke, G. Voss, webVis/instant3DHub: visual computing as a service infrastructure to deliver adaptive, secure and scalable user centric data visualisation, Proceedings of the 20th International Conference on 3D Web Technology, ACM, 2015, pp. 39–47, , https://doi.org/10.1145/2775292. 2775299. [32] J. Dean, S. Ghemawat, MapReduce: simplified data processing on large clusters, Commun. ACM 51 (1) (2008) 107–113, https://doi.org/10.1145/1327452. 1327492. [33] M. Zaharia, M. Chowdhury, M.J. Franklin, S. Shenker, Spark: cluster computing with working sets, Usenix Conference on Hot Topics in Cloud Computing, vol. 10, 2010, p. 95, , https://doi.org/10.1016/j.na.2007.01.001 (10-10). [34] W. Gropp, E. Lusk, N. Doss, A. Skjellum, A high-performance, portable implementation of the MPI message passing interface standard, Parallel Comput. 22 (6) (1996) 789–828, https://doi.org/10.1016/0167-8191(96)00024-5. [35] T. Hoefler, R. Belli, Scientific benchmarking of parallel computing systems: twelve ways to tell the masses when reporting performance results, Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, vol. 73, ACM, 2015, , https://doi.org/10.1145/2807591.2807644. [36] F. Petrillo, P. Merle, N. Moha, Y.G. Guéhéneuc, Are REST APIs for cloud computing well-designed? An exploratory study, International Conference on Service-Oriented Computing, Springer, Cham, 2016, pp. 157–170, , https://doi.org/10.1007/978-3319-46295-0_10. [37] A. Khalili, D.K.H. Chua, IFC-based graph data model for topological queries on building elements, J. Comput. Civ. Eng. 29 (3) (2013) 04014046, https://doi.org/ 10.1061/(ASCE)CP.1943-5487.0000331. [38] S. Rebay, Efficient unstructured mesh generation by means of Delaunay triangulation and Bowyer-Watson algorithm, J. Comput. Phys. 106 (1) (1993) 125–138, https://doi.org/10.1006/jcph.1993.1097. [39] C. Pahl, A. Brogi, J. Soldani, P. Jamshidi, Cloud container technologies: a state-ofthe-art review, IEEE Transactions on Cloud Computing (2017), https://doi.org/10. 1109/TCC.2017.2702586.

Acknowledgements This work was supported by the National Natural Science Foundation of China under grant nos. 71601013 and 61871020 and 61871020, the Youth Talent Support Program of Beijing Municipal Education Commission under grant no. CIT&TCD201904050, the Beijing Natural Science Foundation under grant no. 4174087, the Scientific Research Project of Beijing Municipal Education Commission under grand no. SQKM201710016002, and the Youth Talent Project of Beijing University of Civil Engineering & Architecture. References [1] R. Vanlande, C. Nicolle, C. Cruz, Ifc and building lifecycle management, Autom. Constr. 18 (1) (2009) 70–78, https://doi.org/10.1016/j.autcon.2008.05.001. [2] R. Eadie, M. Browne, H. Odeyinka, C. McKeown, S. McNiff, BIM implementation throughout the UK construction project lifecycle: an analysis, Autom. Constr. 36 (Complete) (2013) 145–151, https://doi.org/10.1016/j.autcon.2013.09.001. [3] T. Cerovsek, A review and outlook for a “building information model”(BIM): a multi-standpoint framework for technological development, Adv. Eng. Inform. 25 (2) (2011) 224–244, https://doi.org/10.1016/j.aei.2010.06.003. [4] C. Eastman, P. Teicholz, R. Sacks, K. Liston, BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers, Engineers and Contractors, John Wiley & Sons, 9780470541371, 2011. [5] M. Oh, J. Lee, S.W. Hong, Y. Jeong, Integrated system for BIM-based collaborative design[J], Autom. Constr. 58 (2015) 196–206, https://doi.org/10.1016/j.autcon. 2015.07.015. [6] A. Ghaffarianhoseini, J. Tookey, A. Ghaffarianhoseini, Application of nD BIM integrated knowledge-based building management system (BIM-IKBMS) for inspecting the post-construction energy efficiency, Renew. Sustain. Energy Rev. 72 (2017) 935–949, https://doi.org/10.1016/j.rser.2016.12.061. [7] E.A. Pärn, D.J. Edwards, M.C.P. Sing, The building information modelling trajectory in facilities management: a review, Autom. Constr. 75 (2017) 45–55, https://doi. org/10.1016/j.autcon.2016.12.003. [8] J.R. Lin, Z.Z. Hu, J.P. Zhang, F.Q. Yu, A natural-language-based approach to intelligent data retrieval and representation for cloud BIM, Computer-Aided Civil and Infrastructure Engineering 31 (1) (2016) 18–33, https://doi.org/10.1111/mice. 12151. [9] D.A. Campbel, Building information modeling: the Web3D application for AEC, Proceeding of the Twelfth International Conference on 3d Web Technology, DBLP, 2007, , https://doi.org/10.1145/1229390.1229422. [10] Y. Jiao, S. Zhang, Y. Li, Y. Wang, An augmented MapReduce framework for building information modeling applications, IEEE International Conference on Computer Supported Cooperative Work in Design, IEEE, 2014, , https://doi.org/10.1109/ CSCWD.2014.6846856. [11] I. Faraj, M. Alshawi, G. Aouad, T. Child, J. Underwood, An industry foundation classes web-based collaborative construction computer environment: WISPER, Autom. Constr. 10 (1) (2000) 79–99, https://doi.org/10.1016/S0926-5805(99) 00038-2. [12] A. Norta, Establishing distributed governance infrastructures for enacting crossorganization collaborations, International Conference on Service-Oriented Computing, Springer, Berlin, Heidelberg, 2015, pp. 24–35, , https://doi.org/10. 1007/978-3-662-50539-7_3. [13] buildingSMART, “Industry Foundation Classes IFC2x Edition 3 Technical Corrigendum 1,” buildingSMART,[online]Available: http://www.buildingsmarttech.org/ifc/IFC2x3/TC1/html (Last accessed: 11/5/2018). [14] IfcOpenShell, [online]Available: http://ifcopenshell.org (Last accessed: 11/5/ 2018). [15] X. Liu, N. Xie, K. Tang, J. Jia, Lightweighting for Web3D visualization of large-scale BIM scenes in real-time, Graph. Model. 88 (2016) 40–56, https://doi.org/10.1016/ j.gmod.2016.06.001.

11