A Framework for Fully Integrated Building Information ...

1 2

Title Page:

3 4 5

6 7 8

A Framework for Fully Integrated Building Information Models in a Federated Environment

9 10 11 12 13 14 15

Corresponding Author:

16

Wawan Solihin

17

Georgia Institute of Technology

18

Email: [email protected]

19

Phone: +1 (404) 448 1165

20

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

A Framework for Fully Integrated Building Information Models in a Federated Environment By Wawan Solihin, Charles Eastman, Yong Cheol Lee Abstract The nature of building projects necessitates building models to be designed by various parties representing disciplines in the Architecture, Engineering, Construction and Owner-operator (AECO) Industries. The federated model emerges as the most practical approach to deal with the various models, especially during design stage, construction coordination and beyond. One of the issues with the current approach is there is no real integration between the various models beyond their spatial co-location. This paper proposes a framework to enable fuller integration of otherwise disparate models into integrated models in the federated environment by enabling two critical concepts - deferred reference and an automatic object snap-in. The concepts are applied in a proposed change to an IFC schema and standardized procedure to enable the automatic snap-in mechanism. With these concepts, models could be designed and exported independently as valid, perhaps partial models and yet will remain integrated when they are inserted into the federated model. A prototype system has been developed to show the effectiveness of such integrated models.

18

Keywords: BIM; IFC; Federated Model; partial models

19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

1 Introduction

40 41 42

2 The federated model: literature review

Models in the life-cycle of a building project are increasingly complex and require evermore closer collaboration between various parties to improve efficiency. A scheme of federated models arises as a practical answer to current issues. Despite the benefits of using federated models, they are currently nothing more than a collection of models that are co-located. Each of the models holds its own structure, points to data only within itself and typically contains redundant or duplicate data [1]. The use of model servers does not alleviate this issue because of the way the data model is currently defined, that is, single-model centric. Even within native BIM authoring tools, federated models are still not fully integrated since separate models are stored in their own documents. Authoring tools such as Autodesk Revit allow references across models, for example to generate a room or space objects. But even with such references, incomplete representations may be generated when the underlying referenced models are unloaded, i.e. an object does not have the right geometry until the referenced models are loaded back to the session [2]. Unfortunately, in general object references will not work in a heterogeneous environment typical to a building project. Unless a new framework that is designed to make the models integrated is introduced, the intelligence expected from federated models would be limited. This paper introduces a new framework to enable models to have references to one another even when they come from different sources. This framework allows the models to be consistent and valid as individual models, and integrated when they are placed together in federated models. This model integration maintains integrity of models including a consistent structure and wellorganized relationships regardless of their modelling environment, eliminating duplicates in geometries and semantics of models.

A building design has never been completely integrated. It is perhaps a legacy that is left over from the historical precedent. Until recently, building projects were commonly designed on paper. With the 1

1 2 3 4 5 6 7 8 9 10 11 12

limitation of paper as a medium, symbolic representations have been broadly used to capture the intent of the building design. They were done in many drawing pages, one set of pages for one category of drawings, e.g. structural, mechanical, landscape, etc. The digitalization of drawings in the early 1970s with the advancement of CAD did not fundamentally change the structure of data. It merely transformed the medium from paper to electronic media, retaining the same symbolic representations in one drawing (or one layer) for each category of drawings. But when CAD advanced to 3D in the 1970s and early ideas of BIM were introduced in the early 1990s [3-5], the building industry was very slow in embracing it and kept to the earlier practice. It somewhat influenced the development of BIM in that BIM continues to rely on individual models to represent various disciplines within the building project. The only form of integration of the models are in federated models. Within the authoring tools, these are usually achieved by linking the files, i.e. XRef in AutoCAD based tools, or link files in Revit.

13 14 15 16 17 18 19 20 21

The development of the IFC schema in 1996 using STEP resource libraries and the Express language [6] maintained the notion of a single model, with a slight tone change that the models should be consolidated into a single IFC file. But in practice, this is never really achieved and it is ever more remote now as the models are increasingly more complex and larger in size, making it impractical to combine them into a single model. The rise of popularity of federated models by tools such as Autodesk Navisworks [7], and Bentley Navigator [8], is the reaction to overcome the limitation imposed by the concept of a single integrated model. Unfortunately, this mode of integration is limited to the support of heterogeneous environment where models from various sources can be federated into one based on the spatial co-location and hardly anything else.

22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

Several papers highlighted the importance of federated models in the AECO industries. The concept has been discussed in several papers as early as the late 1990s. It focused on the collaboration aspect, which works in tandem with the federated models [9, 10]. Both papers recognized that virtually every building project involves multiple participants, often from separate organizations, who need to collaborate with each other in the design process. As discussed in [9], the earlier effort to deal with this topic employed data exchange models starting with IGES, IPAD, PDES, STEP, COMBINE. In these two papers, the approach shifted towards providing a shared and centralized model. Since multiple parties in the building project often use different model authoring tools with their unique data model, such an approach faces an uphill battle to be universally adopted by the design tools. The exchange model seems to be more practical as evident by the adoption of the IFC exchange model by major BIM applications. By defining standard interfaces on what data to exchange, applications continue to have their own liberty to develop the optimized data model internally for their own application and yet allow interoperability with other applications. However, the need to have better collaboration is still critical in a building project. One very successful use of collaboration in practice today is a clash detection. To support clash detection, applications that are able to aggregate data from various formats are found to be popular. They include Autodesk Navisworks and Bentley Navigator. With the rising popularity of IFC, even the freely available IFC-based BIMSight [11] is starting to find a role in this collaboration. The kind of federated model as required by clash detection is still very limited to geometry co-location and mostly still requires human intervention when dealing with the results. Thus the intelligence still resides with human experts to a large extent. For more advanced automated applications such as building rule checking, the federated model must be able to support the intelligence built into the computer applications.

44 45 46

Steel et al [12] outlined the need for collaboration using the federated model with several levels of interoperability that includes file and syntax level interoperability, visualization, semantic, and modelling style level. The file and syntax level interoperability deals with the file format that for the 2

1 2 3 4 5 6 7 8 9 10 11

most part the standard format IFC is able to support. But another issue is also highlighted as part of file and syntax interoperability level, i.e. file size. With the increasing complexity of information that goes into building models, a monolithic approach to the model with the current IFC becomes impractical. Splitting the model into separate disciplines is a commonly used approach, which causes the loss of linkage that is usually built in the authoring applications (Figure 1). Becerik-Gerber [13] also highlighted the need for breaking up the model to deal with the need for collaboration. Rosenman et al [14] took on the issue by proposing a shared model concept that supports a multiple view representing the same building object depending on the domain application that accesses it. This approach resembles the concept in the late 1990s. It also recognizes the semantic level of interoperability. However, the semantic level of interoperability addressed is still limited to the individual element level.

12 13

Figure 1 - Loss of linkages when models are separated

14 15 16 17 18 19 20 21 22 23 24 25

Recognizing the need for much better model integration, the idea of model servers was adopted, partially influenced by the concept of PLM in the manufacturing industries and similar to the earlier approach of a centralized shared model. In a review on BIM data storage and exchange mechanisms, Isikdag et al. [15] described three types of database storage models for building model integration, i.e. a central project database represented by products such as EDM Model Server [16], a federated (loosely coupled) project database as advocated by Bentley in the Bentley white paper [17] and a web services approach as prototyped by the SABLE project [18]. In recent developments, an open source approach of IFC based database servers is gaining traction, represented by the BIMServer project [19]. All of these are based on the IFC schema. Since the IFC schema itself is designed to work as a single model, and separate authoring tools still produce separate models, the servers suffer the same issue of a lack of integration between the models to make up an integrated and coherent building model covering all related models [1].

26 27 28 29 30

The papers reviewed have identified critical needs for collaboration and the use of the federated model is almost assumed. Only a few have recognized the need to support a semantic level of interoperability in the federated model such as in [12] and [14]. But even then the richer set of semantic interoperability that is important in maintaining the consistency of the federated model across different disciplines is largely left unaddressed.

31 32 33 34

This paper deals with what has been unaddressed, namely a semantic model that includes elements and their relationship with other elements regardless of their source. To support that, we propose a framework that enables a flexible approach to integrate models in the federated environment without a single “super” model, but a collection of models that maintain their relationships. This framework 3

1 2 3 4

removes the need for redundant and sometimes inconsistent data in each member model. The framework proposed is based on the IFC schema and it involves small changes to the schema that introduce a concept of deferred references and defining a standard procedure to allow implementation of an object snap-in, a concept not dissimilar with plug-and-play technology.

5

3 Current approach to federated models

6 7 8 9 10 11 12 13 14 15 16 17

There are generally two approaches to handle federated models. The first approach is a proprietary approach that supports multiple heterogeneous file format readers that maps to its own managed data structure (Table 1). Autodesk Navisworks and Bentley Navigator are among the most popular in the AECO industries due to their wide-range support of various BIM native formats. Solibri Model Checker and Tekla BIMSight employ a similar approach although they mainly support the IFC format and provide only very limited support for native formats. The second approach is the use of database servers, otherwise known as model servers. The EDM model server [16] is an example of a commercial implementation of this approach. BIMServer [19] is an open source alternative of such implementations based on the Java platform. Both approaches are based on the IFC schema. As model servers, they offer more than the scope of this paper since they also provide typical database features such as access control, check-in and check-out mechanism, version control, differences, etc. In this paper, the focus is extending model integration based on the IFC schema.

18 19

Table 1 - Applications that address federated models

Product

Internal Data Model Proprietary

Supported Format

Comments

Major 3D formats

Proprietary

Major 3D formats

Tekla BIMsight Autodesk BIM 360

IFC Proprietary

Solibri

Proprietary

IFC, DGN, DWG, IGES Multiple Autodesk format and other third party 3D formats IFC

Designed to spatially coordinate geometry among federated models Designed to spatially coordinate geometry among federated models Does spatial coordination using IFC Developed to support multiple applications, including Revit and AutoCAD Does spatial coordination and model checking using IFC

Autodesk Navisworks Bentley Navigator

20 21 22 23 24 25 26 27 28 29

As previously highlighted, since the IFC schema is designed to be a monolithic model, the model server implementation of IFC suffers from the same restriction. The model server only offers a centralized location in which it is possible to access information in another model as long as the application knows what to look for. In this respect, it is no different from other applications that aggregate several models and spatially co-locate them in one place. One tremendous benefit just from co-location is the availability of the models for spatial coordination such as clash detection. The construction industry has greatly benefited from this capability. But since the models are not fully integrated, users must manage the rest of all the information produced by the clash detection and update the changes required. There are potential side effects of these updates, which users must manually deal with.

30 31 32 33

Integrated models are important especially in downstream applications such as rule or code checking and Facility Management, which live much longer than the models for construction projects. Unfortunately, in the current practice the requirements for FM has been conspicuously absent due to late or no involvement of FM expertise in most construction projects. Several studies showed the 4

1 2 3 4 5 6

importance of FM involvement in the early stage of the project to ensure that the handover models contain the necessary information for the FM operators to take over [20-23] and that their maintenance and operation requirements can be accurately reflected to a building design during the early design phase. Despite these credible demands the need for consistent and integrated models have not yet been addressed adequately. The following discussions highlight several areas that require an accurate model integration.

7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

1. Project spatial structure IFC specifies a well-defined hierarchical spatial structure that allows a project to cover one or more sites, and each site may consist of one or more buildings. Each building may be defined to be a complete (standalone) building or an aggregation of partial buildings, essentially allowing parts of the building to be described separately under an instance of IfcBuilding. One of the use cases is a building complex, which has common parts at the base and two or more towers above. Each of the building in turn may be made of several building stories and in each building storey there may be a series of spaces. Figure 2 illustrates a IFC spatial structure as found in the IFC4 documentation. The design of the IFC model assumes that the spatial structure is consistent throughout the project with just a single spatial hierarchy. However, in practice this hardly happens due to the practice of having different contractors working on different trades, or the inability of the software to handle huge amounts of data, or lack of easy collaboration. This means that a building project is typically a collection of many models in the IFC context, each of which has its own copy of the spatial structure, which unfortunately may not be exactly the same (Figure 3). This recognition requires Navisworks to transform all local or relative coordinate to global coordinates and eliminate the spatial nesting arrangements of users, requiring manual management of locations for updating.

5

1 2

Figure 2- IFC Spatial Structure Relationship Objects

3

4 5

Figure 3 - Current Federated models contain redundant and disconnected objects and spatial structure

6

1 2 3 4 5 6 7 8 9 10 11 12

2. Space containment Space containment, through IfcRelContainedInSpatialStructure, is one of the very essential features for support of Facilities Management and Asset Management functions, after the building project handover. Most, if not all, of the current BIM authoring tools support space containment, but do not support containment across different files, i.e. the space belongs to a different file (link file) than the objects contained in it. Figure 4 illustrates this case. Even though the MEP objects and the furniture inside the same space are reportedly contained in the same space, space number 108, there are two spaces numbered 108, each in a different file: one from architecture (in Revit: Room object) and one from MEP (in Revit, MEP Space object).

13 14 15 16 17 18 19 20 21 22 23 24 25

Figure 4 - Redundant containers and partial containment relationship for each container

3. Systems and system connectivity (including prefabrication assembly) Considering that MEP systems can be large, there is always a possibility that a large interconnected system for a whole building may be split into several files. In most BIM authoring tools today, the connection between members of a system that are separated by different files will not preserve the connection information. Figure 5 shows the connectivity relationship through IfcDistributionPort, IfcRelConnectsPortToElement and IfcRelConnectsPort for MEP system member connections found in the IFC4 documentation. This capability works within a single file. The file boundary limitation is a fundamental limitation for all but a few systems.

7

1 2 3 4 5 6 7 8 9 10 11

Figure 5 - IFC MEP connection relationship using IfcDistributionPort

4. Space boundary The space boundary, represented by IfcRelSpaceBoundary, is crucial information for energy analysis, quantity take-off for cost estimating, and code checking applications [24]. In these applications, the space boundary is assumed to be complete and reliable as their very basic premise for meaningful analyses. In particular, during the conceptual design phase where a model still do not contain numerous objects, space boundaries are critical in cost estimation of walls and slabs, and their finish materials. If this information is missing or not consistent, the results will not be reliable. In many BIM applications today, there are many ways users 8

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

could create the model. For various legitimate reasons, one may split the model into separate files for the façade of the building, the interior of the building and the structural part of the building (e.g. floor slab). This organization can result in incomplete space boundary information if the BIM tool is unable to link the space and its boundary from other linked files, or if it exports the file individually as a separate IFC file. The general strategy practiced today is to partition the project in a manner that minimizes the cut links, even though it is not always possible to do if different organizations are involved. 5. Element connection IFC defines other types of connections between objects. One such connection is IfcRelConnectsPathElements that is used to describe wall connections among others. The connection type between walls, i.e. T connection or L connection, is important especially for importing applications to be able to create the correct connections between walls and recreate or maintain the integrity of the model for the walls. Similar to the situation described in the space boundary above, when external walls as part of the façade are separated in a different file than the internal walls, the connection information is likely to be missing in the resulting IFC model. 6. Version relationship Versioning is an old issue that has never been fully implemented in CAD related design modelling due to the complexity in managing entities and their relationships [25]. One instance of versioning that can be found in the BIM world is in the form of Level of Development (LOD) [26]. It is only beginning to draw attention due to the fact that modelling a building is not a one step process. The building model usually goes through a step-wise process in which the model contains varying levels of detail based on the stage of the project development. One issue that starts to emerge is how one would link the same object that is represented in increasing detail as the model goes through further development. The current BIM tool may not be able to deal with this issue well, especially when the object is simply replaced with a different representation in the subsequent versions. It is noteworthy that CIS/2, the steel fabrication model [27], explicitly defined three parallel models, a design model and a manufacturing model representing two different phases of a project, and a structural model, with cross reference mappings between them.

34

4 Concepts of deferred reference and object snap-in

35 36 37 38

One important observation from the issues above is that all the relevant items deal with IfcRelationship entity and its subtypes. Hence, the key to solving the issues discussed that deals with integration lies with the new approach to deal with IfcRelationship entities. This paper proposes the concept of deferred reference with the following considerations in mind:

39 40 41 42 43 44

1. The federated model scheme is here to stay. Models may be structured by system or spatially, or possibly other aspects. The proposal will harness the federated model scheme by allowing creation of valid albeit partial IFC models (partial is because certain references may be missing in the file, hence the name “deferred reference”) 2. Changes proposed to the IFC schema are simple and allows smooth backward compatibility. 3. Changes proposed to the IFC schema is simple enough for BIM authoring tools to implement

9

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

4. Not everything can be dealt with at the schema level. It will require standardized procedures or standardized specifications for export and import implementations to support the combination of the deferred reference with automatic snap-in capability.

4.1 The concept of deferred reference In the current IFC schema every relationship is represented with one of the subtypes of IfcRelationship. It links two or more entities via its attributes that has direct reference to the linked entities. In this case we are interested in building products (Figure 6). This design requires both ends of the building products to exist in the model, otherwise it will form an incomplete or invalid model, and violate the schema integrity. In the event where two or more connected models need to be exported separately, a special arrangement is needed to maintain the link between related objects without the presence of the objects. Figure 8 shows the proposed change to IfcRelationship entities allowing the reference to an object to be represented by a minimum reference, mainly its GUID. A new generic entity is IfcDeferredReference. IfcDeferredReference is a subtype to IfcObjectDefinition is defined for this purpose (Figure 7). The use of deferred reference to an “incomplete” object specification by its GUID allows validity of the model and provides the necessary information to resolve the reference at a later stage when the object with the associated GUID is present in the federated model. RelatingStructure [1:1] IfcSpatialElement

RelatingStructure [1:1]

IfcSpatialElement

IfcRelContainedInSpatialS tructure

IfcRelContainedInSpatialS tructure

IfcBuildingStorey

19 20

RelatedElements [1:?] IfcProduct

RelatedElements [1:?]

IfcProduct

IfcWall

Figure 6 - Current IfcRelContainedInSpatialSturcture entity definition and the typical instances in the model

21

10

IfcDeferredReference

IfcRoot

IfcObjectDefinition

IfcDeferredReference

IfcRoot GlobalId OwnerHistory Name Description IfcObjectDefinition IfcDeferredReference ReferenceType: OPTIONAL IfcLabel

IfcDeferredReference IfcDeferredReference defines a simple reference to another entity through the GlobalId of the object it refers to. It provides a simple mean of reference to another object, which may not present in the model. This allows a reference to be resolved later on when the referenced entity becomes available, hence the name deferred reference. ENTITY IfcDeferredReference SUBTYPE OF (IfcObjecDefinition); ReferenceType : OPTIONAL IfcLabel; END_ENTITY;

Attribute Definitions: ReferenceType referenced GUID. Inheritance Graph: ENTITY IfcDeferredReference ENTITY IfcRoot GlobalId OwnerHistory Name Description ENTITY IfcObjectDefinition

: The description of the type of reference this entity represents. This provides further information about the

: IfcGloballyUniqueId; : OPTIONAL IfcOwnerHistory; : OPTIONAL IfcLabel; : OPTIONAL IfcText;

INVERSE HasAssignments : SET OF IfcRelAssigns FOR RelatedObjects; IsDecomposedBy : SET OF IfcRelDecomposes FOR RelatingObject; Decomposes : SET [0:1] OF IfcRelDecomposes FOR RelatedObjects; HasAssociations : SET OF IfcRelAssociates FOR RelatedObjects; ENTITY IfcDeferredReference ReferenceType : OPTIONAL IfcLabel; END_ENTITY;

1

Figure 7 - The new IfcDeferredReference Entity inherited directly from IfcObjectDefinition

2 3 4 5 6 7 8 9 10 11

The relationship objects in IFC will have a new Select type for both attributes referencing both sides of the relationship. Figure 8 shows a diagram of the use of this select type for IfcRelContainedInSpatialStructure. The Select type allows a choice of either the actual IFC object, which is the original IFC specification, or the IfcDeferredReference entity that keeps a GUID to the actual IFC entity it eventually should refer to. In all cases of deferred references, it makes sense that only one side of the relationship object has the deferred reference while the other side refers to an IFC entity present in the current model. To achieve this, a constraint OnlyOneDRef is applied to the relationship object to limit the reference only to one side of the select type to the IfcDeferredReference (Figure 9).

11

RelatingStructure [1:1] IfcSpatialElementDRefSelect

IfcRelContainedInSpatialS tructure

RelatedElements [1:?] IfcProductDRefSelect

1

IfcDeferredReference

1

IfcSpatialElement

IfcProduct

IfcDeferredReference

1 2

Figure 8 - Express-G diagram of IfcDeferredreference using a select type

ENTITY IfcRelContainedInSpatialStructure SUBTYPE OF (IfcRelConnects); RelatedElements : SET [1:?] OF IfcProductDRefSelect; RelatingStructure : IfcSpatialElementDRefSelect; WHERE WR31 : SIZEOF(QUERY(temp