1

Evaluation of Interoperability in Construction Programs Using the IFC 4

Universidad de Los Andes

Department of Civil and Environmental Engineering

Santiago Quintero Botero

Prof. M.Sc. Laura Andrea Gutiérrez Bucheli

November 2018

Abstract

BIM projects were defined as “value creating collaboration through the life cycle of an asset, underpinned

by the creation, collation and exchange of shared 3-dimensional models and intelligent structured data

attached to them” (Yousefzadeh, Spillane, Lamont, Mcfadden, & Lim, 2015). So, data exchange among

construction programs is a very relevant aspect of construction projects. Since the introduction of

different technology programs there has been a concern with the standardization of data exchange

between construction programs. From 1997 the Industry Foundation Classes (IFC) was released, and it has

enabled the exchange and sharing of information between building information models. The last version

of IFC was the IFC 2x4 released in 2010, and it included several improvements to reduce the

interoperability problem in construction projects. However, in this research the interoperability between

different construction programs was evaluated using the IFC 4. The programs selected were Revit, Allplan,

SAP 2000, EPANET and Plexos, and a four-story building was modelled. In the results the interoperability

when transfering the model using the IFC 4 are mentioned. The conclusion of this paper is that although

IFC data transfer could help to reduce time by transfering the construction models, there are still a lot of

innacuracies to resolve. The academia, industry and software vendors should work together to mitigate

the interoperability problem among BIM construction programs.

Introduction

Building Information Modelling (BIM) has different definitions in the construction sector. According to

Yousefzadeh, Spillane, Lamont, Mcfadden, & Lim, 2015, one of the most recognized definitions of BIM is

provided by the BIM Task Group (2013), which states that BIM is “value creating collaboration through

the entire life-cycle of an asset, underpinned by the creation, collation and exchange of shared 3-

dimensional models and intelligent, structured data attached to them”. The exchange of information in

BIM construction projects among stakeholders is very important. The architectural, structural and MEP

designers are usually different persons, and they all participate in the 3-dimensional modelling of a

project. Finally, when the 3-dimensional model is perfect, it is used by several stakeholders.

As construction projects are multidisciplinary, data transfer is very important. Different technological

programs are involved in 3-dimensional modelling. Usually, stakeholders need to import project data from

2

one software to another. Unfortunately, software vendors have different ways of managing the

information of a project, so transferring information from any BIM program to another may represent a

problem. As a result, selecting the programs that are going to be used by the Stakeholders in a project

may influence the way in which data will be exchanged between the stakeholders of a construction

project.

In the moment of planning the BIM Execution Plan (BEP) of a project it is important to decide whether it

will be a closed BIM or an open BIM project. These two approaches are different ways of conceiving the

3D BIM modeling. Closed BIM is a BIM environment were the same software or same software vendor is

used by all the stakeholders. This process is restrictive because it only allows the stakeholders to use

specific BIM software to collaborate, however this reduces the problems of interoperability in the project.

In the case of the open BIM, all participants can collaborate and exchange project information using

neutral file formats. In this method the stakeholders can use different software without any restriction

since the file for information exchange is neutral. Open BIM has worked on different protocols and open

standards on construction projects.

For this research, the interoperability between different construction programs will be evaluated for

different construction processes such as 3-dimension modelling, structural design, plumbing design, and

scheduling planning. It is also important to state that the information exchange method used will be the

Industry Foundation Classes (IFC). It is an open BIM protocol to exchange information of a project with

the use of a neutral file among different construction programs. The IFC is not controlled by a single

vendor or a group of vendors.

State of The Art

Filippo Brunelleschi implemented the idea of Building Information Modelling (BIM) to vault the massive

dome over Santa María del Fiore in Florence in 1419 (Garber 2014). He is the most notable master builder

from the period immediately before the Renaissance, and even though he had no access to technology at

this time, he used the principles of using a model for planning a construction project. BIM has been

present in the construction processes through history, and it is a philosophy for making projects where

the stakeholders must exchange information and work as a team to construct a model before starting

construction. Good planning of a project prior to the construction is very important because changes

become more expensive as time passes, so it is important to make decisions before the construction

starts. With the creation of new technologies, modern BIM philosophy intends to implement an

integrative way of working; this means that they intend to represent how the real project will be built

using a computer model. In this type of projects, all the stakeholders participate in the planning phase so

that interferences between different systems can be solved before the construction starts. However, in

the past decades, a problem of interoperability and standardization have been a limitation between

stakeholders in a project when they are going to pass the model information from one software to

another.

Standardization for data exchange

The introduction of different technology programs initiated a transition in the way the tools were used in

construction processes. First was the transition from pen and paper to Computer Aided Design (CAD)

3

software. Now, a transition between CAD software to BIM software is still happening. Advances in product

data exchange from the early days of CAD through the release of STEP (Standard for the Exchange of

Product Model Data) can be divided into three distinct generations of data exchange methods, which are

the ad-hoc solutions, neutral CAD standards and STEP standards.

Product data exchange methods from the 1950s to the 1970s were used exclusively depending on each

company. There was a rapid pace of technological development and the needs for data exchange was

limited. As a result, computers at this time were used for specific tasks, for speeding up and other

automating tasks which could also be executed manually (Laakso & Kiviniemi, 2012).

Later in the 1970s, the second generation of exchange standards is characterized as a period when tools

for basic geometry representation began to emerge. Needs for information exchange in CAD models

became present, and as an example one of the most notable efforts was IGES (Initial Graphics Exchange

Specification). In 1980 IGES released a new version with an agreement involving important CAD users and

the leading CAD vendors to develop an open exchange mechanism of information. Although the process

of CAD standardization was a fast standardization cycle of about a year, IGES could not gain significant

relevance in a time where 3D modeling started to be viable (Gallaher 2002).

In 1984 the ISO/TC184&SC4 (Subcommittee 4 of ISO/TC 184, Automation systems and integration, which

is Technical Committee 184 of the International Organization for Standardization) declared that none of

the existing formats could serve the needs of an open computer modeling standard (Bloor & Owen 1995).

This ISO declaration marked the beginning of STEP and a generation with a big concern on standardization

of data exchange in the construction industry. The STEP ideology consisted of having common universal

resources at the core of a comprehensive standard, with the capability of covering a diverse range of

industries. The idea was to reduce redundant standardized work and enable future industry collaboration.

Interoperability

The construction industry involves interdisciplinary work among different professionals, which often use

IT programs as tools to develop their jobs. For over 20 years construction researchers have studied the

exchange data and interoperability of product model for construction. In 1995, according to Björk &

Penttilä (1989), five requirements for an open building product model standard are that they should: 1)

encompass all building information, 2) meet the information needs of all stakeholders, 3) be non-

redundant, 4) be software independent, and 5) be format independent. Two years later, Eastman, Bond,

& Chase, 1991 suggested the following for product model standard: 1) represent function and form, 2)

support the product lifecycle and multiple levels of abstraction, 3) provide general semantic

representation, 4) provide extensible semantics.

These requirements developed by early IT researchers were abstract and did not considered limitations,

however, they encompass much of which the IFC standard incorporated some years later. In 1994,

Autodesk developed an industry consortium, known as the Industry Alliance for Interoperability.

However, in 1997 there was a change in the name of the organization to International Alliance for

Interoperability (IAI). In the following section the development of IFC different versions will be discussed

and the transition from IFC 1.0 to IFC 2x4.

4

Despite the development of different IFC versions lack in modeling data operability and limitations on

different BIM software have been a relevant problem. According to a GCR 04-867 report, published by the

National Institute of Standards and Technology (NIST), the lack of operability between software platforms

cost the United States of America approximately $15.8 billion in 2002 alone, prior to the widespread

emergence of BIM within the construction sector. This report also states that “Interoperability problems

in the capital facilities industry stem from the highly fragmented nature of the industry, the industry’s

continued paper-based business practices, a lack of standardization, and inconsistent technology

adoption among stakeholders” (Gallaher, O’Connor, Dettbarn, Jr., & Gilday, 2004).

In 2006 the IAI consortium was renamed to buildingSMART, this change characterized a greater emphasis

on the business benefits of an interoperable integrated design and construction process. There was a

change in the vision of the organization. According to Stangeland, “the old vision was formulated as ‘To

enable software interoperability in the AEC/FM industry’. The new vision goes beyond technical aspects

to emphasize what interoperability means for users and business: ‘Improving communication,

productivity, delivery time, cost, and quality throughout the whole building life-cycle’” (Stangeland,

2009) .

However, one year later there were still interoperability problems. In 2007 Young, Jones and Bernstein

stated that “The majority of this cost was attributed to redundant data entry, redundant IT systems and

IT staff, inefficient business processes, and delays indirectly resulting from these inefficiencies. Another

recent US survey suggested that software non-interoperability costs on average 3.1% of total project

budgets” (Young, Jones & Bernstein, 2007). Also, at this point, major IFC releases were present in leading

BIM software for more than ten years. However, real-world use of the formats as an enabler of

interoperability between project actors was still low (Kiviniemi et. al , 2008;Young et. al 2007). Similarly,

in 2008 Goedert and Meadati stated that interoperability has emerged as one of the most inhibiting

factors to the widespread adoption of BIM within the construction sector (Goedert & Meadati, 2008).

However, Kiviniemi in 2008, that there was an interest in using Building Information Models (BIM) as a

central design and information management media in construction projects around the world. He also

stated that private companies have started to deploy BIM in their internal processes and supply chains.

This situation increased a market need for emerging model-based data exchange between different

applications in everyday projects. In 2009 Veras X. de Andrade & Coeli Ruschel conducted a study that

consisted of modelling a building in Archicad and Revit. Afterward, both models were exported to IFC

format and they were compared to identify inconsistencies with the original model. Results concluded

that when the model was exported to IFC format quality was lost. In fact, geometry loses were present in

a few components and were not a major limitation in the general understanding of the project. Also,

information losses in both software when exporting to IFC was different and not consistent, which was

the reason that Veras X. de Andrade Et. All concluded that the problem was not in the IFC format

generation, but in the translators used. Finally, property losses from Revit and ArchiCad were significant

which could make the use of the model inviable. The author of this study stated that OPS could be used

to reduce information loses.

In 2010 IFC 2x4 release took place and “extended the capabilities of the IFC schemas into new areas of

high demand, like GIS connection, 4D and 5D models, thermal simulations, environmental impact, base

quantities, and many others” (Liebich, 2010).

5

In 2015 there was still interoperability problems. “Various types of BIM interoperability exist including the

lack of data transferring (missing data), erroneously translated data, and files with a unique format that

would simply not open in a different software platform” (Yousefzadeh et al., 2015).According to this study,

the construction sector should take proactive steps to mitigate and preferably eliminate interoperability

between the respective software packages in the pursuit of attaining level 2 BIM. Yousefzadeh et al. also

conducted a study with two approaches to mitigate interoperability problems between two software

platforms, Revit and a Finite Element Analysis Software. Direct links were used in this investigation to

exchange data between two BIM software platforms. Also, IFC files were used to open and modify various

BIM software packages. Finally, this work concluded that the exported model through direct links is

usually more accurate than that of IFC model. Therefore, this paper highlights that, although Industry

Foundation Classes (IFCs) are the means to exchange data and information related to a BIM project, using

direct-link to transfer data is more reliable and accurate process.

IFC development

Autodesk developed the industry consortium, known as the Industry Alliance for Interoperability, which

was changed to International Alliance for Interoperability (IAI). From 1997 the Industry Foundation

Classes (IFC) was released, and there have been different versions to enable the exchange and sharing of

information between building information models (BIM). According to Dr. Thomas Liebich in 2010, IFC

releases started in 1996 with IFC 1.0, which was a prototype and helped to produce stability for the IFC

1.5 release. Afterward, the IFC 1.5.1 had a minor update and was the first IFC release with commercial

implementations. “The scope was mainly the architectural part of a building model.

Meanwhile the next release, IFC 2.0 had been developed with support for several new exchange

requirements, including a first schema for building services, cost estimation, and construction planning”

(Liebich, 2010). After 2.0, architectural issues with the structure, modularity and extensibility of the IFC

schema were discovered and led to the release of IFC 2x. In 2003 came the next larger change with IFC

2x2. In this version, “the new schema extensions there had been 2D model space geometry, presentation

(color, shading, hatching, etc.), an extension of the building service component breakdown, structural

analysis (loads, analysis model), structural detailing, support for building code checking and facility

management. The extensions had been the final result of an IFC extension project framework formalized

as part of the IFC2x platform development process” (Liebich, 2010).

Despite IFC releases, report on the costs of inadequate interoperability (Gallaher et al., 2004) highlighted

the need for standards in data exchange. Also, “the interest and need for having an open BIM interface

have increased since around 2005 in parallel with a broader acceptance of BIM in general” (Grudger 2007).

This increased IFC interest and finally IFC 2x3 achieved a breakthrough with the coordination view. This

version was released in 2006, which is the previous version of the last IFC release, the IFC 2x4.

With the IFC 2x4 final version, there was a release cycle which took place from 2006 to 2010. The main

objective for the development process was to “put quality over speed”, which was important because it

gave the developers enough time and stability to embrace IFC 2x3 baseline.

6

For this research purpose, a general review of new enhancements that IFC 2x4 included will be listed. This

was taken from the “what´s new in IFC 2x4” section of the Building Smart webpage. Liebich in 2010 also

made documentation of IFC 2x4.

Core Definitions -There is a new concept to define the register of all types (families or styles). Product types can now be decomposed into parts. -The IFC object definition inheritance tree is now synchronized

Building Elements -Major subtypes of building element, slab plate, beam, column, member, door and window have been separated into a general definition and a specific specialization to represent the standard cases for a parametric exchange of its shape, material and underlying element type. -All longitudinal elements can now carry an axis representation and a cardinal point to describe the position of the profile related to the axis. All planar elements can now carry a surface representation.

Building Service Systems -A specialization of System has been added to capture the concepts of a distribution system in a new element. Now the distribution systems have a predefined type for plumbing.

Structural modeling and detailing elements - Cross section definition of columns, beams and similar elements is enhanced. Section

geometry and material information are now associated with building elements.

Geometry -Additional entities are added to the geometry resources

Coordinate Systems -The IFC data set which used Cartesian coordinate system can now include project information to place it in any geographic coordinate system.

Processes -The concept of a process type and relevant subtypes has been introduced. -It is possible to define work calendars with various recurrence patterns and assign them to work schedules, work tasks and resources. This new process definitions significantly reduce the model footprint when capturing 4D datasets.

Costs -Definition of cost values have been simplified. They are now attached to cost items and not to a relationship. The documentation has been improved on how to use cost schedules, cost item hierarchies, and cost values. This is intended to reduce the model footprint in 5D modelling.

7

However, after the IFC 2x4 release it is not clear how the problem of interoperability between

construction programs improved. Although the new version of IFC includes several enhancements for

defining projects there is still a problem of how data is transferred among different construction

programs. Some software vendors are more compromised than others with the standardization of

transferring the data among different programs. Therefore, it is important to evaluate how the

information from different models is transferred between different programs

Methodology

The interoperability between BIM construction software packages using IFC 2x4 will be studied. First, a

review of the state of the art is conducted to understand the development of the industry in relation with

BIM software. It is also relevant to understand how the process of standardization for data exchange and

the development of the IFC format were developed so that the interoperability between different BIM

software could be possible.

For this research some BIM technologies were selected; 2 programs of 3D BIM modeling; 1 BIM program

on schedule planning; 1 program used for the industry in Colombia for plumbing modelling and 1

frequently used program for structural modelling, a brief description for these BIM technologies is

provided below:

Autodesk Revit 2019: From the Autodesk family includes Revit Architecture, Revit Structure and Revit

MEP (Mechanical, Electrical and Plumbing). “Revit Architecture is one of the best-known BIM software in

architectural design”(Chen & Gehrig, 2011). One of the most important aspects of Revit modelling is that

it enables to create parametric 3D models. To represent objects, Revit uses families which can be

downloaded or created depending on each project requirements. Revit can also interface with other

software through IFC 2x4. In the case of Revit, the program offers two configuration options of IFC 4

exportation, the IFC 4 Design Transfer View and the IFC 4 Transfer View. For this research, the model will

be exported using both formats.

Nemetschek Allplan 2018: Like Revit, Allplan is a very important BIM software used for 2D/3D parametric

modelling. It is used for architectures and engineers in construction projects. This software can import

and export in IFC 2x4.

CSI: SAP 2000 v 2019: Computers and Structures Inc is recognized globally as the pioneering leader in

structural engineering analysis and design software tools for structural and earthquake engineering (CSI

2018). Software from CSI like SAP 2000 is used by thousands of engineering firms in over 160 countries,

including Colombia, for the design of construction projects. For this research SAP 2000 v 2019 will be used.

EPANET 2.0.12: Is a water distribution system modelling software package. It was developed by the United

States Environmental Protection Agency (EPA), and it is “used throughout the world to model water

distribution systems. This software application is used to perform extended- period simulation of the

hydraulic and quality behavior within pressurized pipe networks, which consist of pipes, nodes (junctions),

pumps, valves, storage tanks, and reservoirs” (EPA 2018).

Plexos Project Beta version: “Plexos is a production planning system that applies the most recent

developments in scheduling algorithms under LEAN principles. […] Is totally integrated with BC3 cost data

format (local files or cloud databases) and allow 4D/5D scheduling based on BIM IFC files” (Plexos 2018).

8

As a case study, a four-story project will be used to evaluate the data exchange process between the BIM

technologies listed above. The structural material used will be concrete and sections will be rectangular.

Taking to account Figure 1 which shows a typical workflow and coordination process adopted in

construction projects, the data exchange of information between BIM technologies selected for this work

will be evaluated using IFC 2x4 format. As it is shown in Figure 2, first the data exchange will be evaluated

between Revit 2019 and Allplan 2019 using IFC 2x4. Then the interoperability of the structural designing

software, plumbing software and BIM schedule planning will be evaluated with Revit 2019 and Allplan

2018 as shown in Figure 3. Finally, after analyzing the capacities and limitations of each software regarding

IFC 2x4 data exchange, conclusions and recommendations will be provided.

1.0 Workflow and coordination processes used in typical BIM projects

Figure 1- Workflow and coordination processes used in typical BIM projects

9

2.0 Workflow to evaluate data exchange between Revit 2019 and Allplan 2018 using IFC 2x4

Figure 2- Workflow to evaluate data exchange between Revit 2019 and Allplan 2018 using IFC 2x4

3.0 Workflow to evaluate data exchange between SAP 2000, EPANET, and Plexos with Revit 2019 and

Allplan 2018 using IFC 2x4

3.1 3.2 3.3

Figure 3- Workflow to evaluate data exchange between SAP 2000, EPANET, and Plexos with Revit 2019 and Allplan 2018 using IFC 2x4

10

Results

Interoperability when exporting a model using an IFC 4 file from Revit 2019

The results according to the methodology wil be shown. Starting with Revit 2019, the steps shown in

workflow 1.0 were followed to test the interoperability limitations that a typical BIM project could face.

Interoperability between Allplan 2018 and Revit 2019

Transfer of the architecture, structure and plumbing from Revit 2019 to Allplan 2018 using IFC 4 Design

Transfer View

To evaluate the interoperability between Allplan and Revit, a four-story building was modelled. According

to workflow 2.0, the model was first exported from Revit 2019 to IFC using the IFC 4 Transfer Design View

options. When importing the model from Revit to Allplan using the IFC 4 Transfer Design View, there is a

report generated in Allplan. The report indicates the number of elements created compared to the ones

contained in the IFC file. In the case of the four-story building, the report showed that several elements

were lost in the model imported.

Once the model was imported to Allplan the main characteristics of the original model were preserved.

However, differences and interoperability problems were clear. The grid was not imported. Now the

structural, architectural and plumbing system will be analyzed.

According to the structural system, the elements imported were accurate in terms of location,

dimensions, and materials. However, most of the elements were not correctly joined, and were separated.

It is clear how some structural elements were ignored in the moment of importing the model, but the

elements created preserved the same characteristics as in the original model.

In the case of the architectural system there were also some interoperability problems. Looking at the

model some elements were missing. Also, the geometry of some elements created in the new model were

not accurate compared to the original model and intersection between some architectural elements

presented problems. Finally, some Revit families were different from the elements created in Allplan, and

other specific families were ignored.

The plumbing system was imported separate from the architectural and structural systems. So, in this

importation, the report indicated much more interoperability problems compared to the structural and

architectural case. When the plumbing model was imported in Allplan, the elements from the plumbing

system were classified as “User Defined Architectural Elements”. However, the intersections were not

correctly imported. All the elements that were part of the intersections were ignored. As a result, each of

the elements created from the plumbing system were separated. Finally, the elements had no material or

dimensions associated to their properties. In general, the model imported presented important

differences compared to the model.

11

Transfer of the architecture, structure and plumbing from Revit 2019 to Allplan 2018 using IFC 4

Reference View

As in the case of the IFC 4 Design Transfer View exportation, the IFC 4 Reference View was used to export

the model to Allplan according to workflow 2.0. So, when the model was imported to Allplan, a report

was created saying that no elements were ignored in this importation compared to the original model.

However, when the model was observed it was clear that a few elements were missing. Also, no grid was

imported.

Starting with the structural system, the geometry was better imported than in the previous case. Most of

the structural elements were imported correctly in terms of geometry, materials or element attributes.

However, in this importation a few elements were ignored. Intersection of elements were also defective.

There were no joins at the intersections, and most of the elements were separated.

Following the architectural model, most of the elements were observed to be imported correctly.

Although several parts of the model were not completely accurate, it was clear the improvement

compared with the IFC 4 Design Transfer View case. The elements were accurate in terms of location,

geometry and material. Also, in this importation all Revit families were identified and imported, although

some elements in Allplan were very different to Revit families. At last, intersection problems between

some architectural elements were still present and this implied significant inaccuracies between the

original and the imported model.

Following the same steps, the plumbing system was imported to Allplan now using the IFC 4 Reference

View. This time there were no elements ignored, which indicates an improvement compared to the

previous plumbing system importation using the IFC 4 Design Transfer View. When the plumbing model

was opened in Allplan the improvement was clear. No element was observed to be imported without any

geometry inconsistencies and plumbing elements were assigned as “Defined Architectural Elements”.

However, the elements had no material or any other attributes assigned. The intersections were very

accurate, and the elements were connected. In this importation the elements of the intersections were

correctly imported. Only a few elements were ignored. In general, the new model imported was consistent

with the original, with the exceptions mentioned above.

Interoperability between SAP 2019 and Revit 2019

Transfer of the structural model from SAP 2000 V.2019 to Revit 2019 using IFC 4

For this case a four-story building was modelled using SAP 2000 V.2019 according to workflow 3.1. Grids,

frame sections, materials and height elevations were created in the model. Each element was assigned a

frame section and a material. Later, an IFC 4 file was created using SAP 2000. It is important to note that

SAP has two options of exporting the model, they are Architectural Coordination and Structural Analysis.

Although the model was exported using both options, in the Structural Analysis exportation no element

was created in Revit. The results of the Architectural Coordination exportation will be mentioned.

When opening the IFC 4 file of Architectural Coordination in Revit created by SAP 2000, the new model

was perfectly exported in terms of geometry. All the elements were created, with consistent dimensions.

12

Height elevations were consistent, and levels were created in Revit with the correct dimensions. However,

grids were not imported and there were some interoperability problems with the element families and

properties. Also, the intersections between elements were not accurate because no element join was

created. It was observed that these sections overlapped causing overcounting problems. It is also

important to mention that element connectivity in SAP 2000 is usually created between the center of the

elements, therefore it assumes that all the intersections occur exactly in the center of every element. This

is not always the case, therefore some intersections were not accurate compared to the correct form of

constructing the structure in a project. This was a limitation due to the way that SAP 2000 models the

nodes between elements. In terms of Revit families, Revit could identify correctly the family type of each

element, and the user could indicate which family was assigned to each IFC element category. However,

the element attributes such as materials and dimensions, were not imported. Finally, in terms of

parametrization, there were also problems because vertical elements had only the base floor

parameterized, not the top floor.

Transfer of the structure from Revit 2019 to SAP 2000 V.19 using IFC 4 Design Transfer View and IFC 4

Reference View

After transferring the structural system from SAP 2000 to Revit 2019, the exchange of the model was

evaluated when transferring the model from Revit 2019 to SAP 2000 according to workflow 3.1. First the

model was imported using the IFC 4 Design Transfer View, then the IFC 4 Reference View exportation from

Revit was done. It was observed that results in both importations were the same. Grids and levels were

not imported, and it was not possible to see all the elements of the model in the XY,XZ and YZ view. The

only way to look at them was by the 3D view. Another important thing of the model imported was that

materials and frame sections were imported correctly. This frame sections imported were only one

created for each family type that were originally created in Revit. The opposite happened when the IFC 4

file of the structure created in Allplan was opened in SAP, for one different frame section was created per

element. Also, the attributes of the material concrete created in the IFC importation had the correct values

corresponding to concrete. Finally, all the elements were disconnected, and they were not drawn to the

middle of the axis, which is the way that SAP 2000 models construction projects.

Interoperability between EPANET and Revit 2019

EPANET is a plumbing design software in 2D used for hydraulic systems. It is important to state that this

represents a limitation for BIM projects. If the plumbing system is intended to be modelled in Revit for

coordination between other systems, it is not possible to import it from an EPANET model. In fact, EPANET

does not include an option to import a IFC file. However, it is possible to download a free program EPACAD

where it is possible to transfer an Autocad file to EPANET. This implies that to transfer the Revit plumbing

system it is necessary to export each floor plan to Autocad, then to EPACAD and finally to EPANET.

However, when this process was done according to workflow 3.2 it was clear that not all the model was

accurate and there were interoperability problems. Some elements were ignored, and they had to be

drawn again. Element properties such as diameters and roughness were not always accurate.

13

In the other hand, transferring the model from EPANET to Revit is not possible. EPANET is a 2D modelling

software, therefore the data would have to be passed to Autocad. However, if the model is opened to

Revit using Autocad it would be a 2D drawing and no 3D element would be created. So, passing the

plumbing system from EPANET to Revit would only be useful for having a 2D representation in Revit and

this would facilitate the modelling in Revit.

Interoperability between Plexos and Revit 2019

Transfer of the architectural, structural and plumbing model from Revit 2019 to Plexos using IFC 4

Design Transfer View

To evaluate the interoperability between Revit 2019 and Plexos, the model was first exported using the

IFC 4 Design Transfer View according to workflow 3.3. Although the height elevations were imported

correctly, the result was very similar to the model imported to Allplan from Revit using the IFC 4 Design

Transfer View. Interoperability problems in both importations were the same. In fact, Allplan ignored the

same elements as Plexos in the IFC 4 Design Transfer View. Also, the same families ignored by Allplan were

ignored by Plexos. Finally, the same intersection problems were also the same in both cases.

Transfer of the architectural, structural and plumbing model from Revit 2019 to Plexos using IFC 4

Reference View

After evaluating the IFC 4 Design Transfer View, the IFC 4 Reference View from Revit was going to be

evaluated in Plexos according to workflow 3.3. However, when opening any IFC 4 file created by Revit

using the IFC 4 Reference View, Plexos generated an error saying ‘’Invalid IFC format, open the IFC file in

a BIM specialized tool and try to re-export it’'. This can be a limitation because in the exportation from

Revit to Allplan, the IFC 4 Reference View was much better than the IFC 4 Design Transfer View.

Interoperability when exporting a model using an IFC 4 file from Allplan 2018

Now, another four-story model was created in Allplan to export it as IFC 4 file and test the interoperability

limitations that a typical BIM project could face according to workflow 1.0. In this case when the model is

exported to an IFC file a report is generated by Allplan, like the one generated when an IFC file is imported

to the program. This report indicates which elements are generated and which are ignored in the

importation. In this case all the elements were successfully exported to the IFC file.

It is important to mention that Allplan does not have MEP modelling, as Revit does. This is a limitation if

the user wants to model the plumbing system. However, there are several ways to model the plumbing

system in Allplan. For this case, the pipes were modelled as an extrusion of two circles along a path. After

creating the pipes, it is important to convert the 3D object in Allplan to a user defined architectural object

and to indicate that it will be classified as a IFCBuildingElementProxy in the IFC exportation.

14

Interoperability between Allplan 2018 and Revit 2019

Transfer of the architecture, structure and plumbing model from Allplan 2018 to Revit 2019 using IFC 4

According to workflow 2.0 the interoperability between Allplan and Revit was tested, this time importing

the model to Revit from Allplan. Although Allplan 2018 and Revit 2019 support IFC 4 transfer of data, it

was not possible to see the imported model from Allplan 2018 in Revit 2019 by the IFC 4 file. The levels

seemed to be imported correctly and according to the program the elements were created. However,

after checking the visibility view settings it was not possible to see the elements created. Trying to fix this,

the same IFC 4 file created in Allplan was opened by Revit 2018 and then opened in Revit 2019. This time

the model was imported correctly, therefore the results will be analyzed now.

The structural model interoperability was very bad. Although all the structural elements were created in

Revit, materials, geometry and location of the elements were not accurate. Elements had no dimensions

associated and the loss of information was a big. Element shape was completely inaccurate. In fact, every

time the user changed the model view, shape, location and dimensions were not constant. Some elements

were only parameterized in the bottom of the floor, but not with the top floor. Other elements were not

parameterized. Finally, the intersection of elements were also very inaccurate.

The architectural elements presented the same problem of geometry as the structural elements. They

were not constant as the user changed the view model. Although all the architectural elements seemed

to be imported, they had great inconsistencies compared to the original model. Although Revit families

were correctly identified by Allplan, the loss of information was very big. In general, the architectural

elements were parameterized only with the bottom floor, as in the case of the structural model.

In the case of the plumbing system elements, they were all imported. Diameter and other the material

properties were not correctly imported. As in the case of the architectural and structural elements the

element geometry is was not consistent when views were changed. Loss of information was very big.

Interoperability between SAP 2019 and Allplan 2018

Transfer of structure from SAP 2000 V.19 to Allplan 2018 using IFC 4

As in the transfer of the structure from SAP 2000 to Revit, the process in workflow 3.1 was followed to

test the data exchange from SAP 2000 to Allplan. Although the IFC files were created using Architectural

Coordination and Structural Analysis, Allplan was not able to import the Structural Analysis file. Therefore,

the results of the Architectural Coordination will be mentioned.

The importation from SAP 2000 to Allplan was very accurate. All the elements except one were imported

with the correct location, dimension and material assignation. The only element ignored was not a regular

rectangular section, but an I section. This could represent a limitation for Allplan for identifying not regular

rectangular sections. In terms of intersections, some elements were not drawn the entire length as they

would have in a real construction project. In fact, some elements were drawn to the middle of the

intersection, as it is the way SAP models the intersections. This is not always the case, therefore some

intersections were not accurate compared to the correct form of constructing the structure in a project.

This was a limitation due to the way that SAP 2000 models the nodes between elements.

15

Transfer of the structure from Allplan 2018 to SAP 2000 V.19 using IFC 4

In the case of the Allplan to SAP 2000 according to workflow 3.2, it was not possible to open the model.

When the IFC file created in Allplan was opened in SAP 2000, no element or grid was created. However,

materials and frame sections from Allplan were created in the SAP 2000 model. One frame section was

created for each structural element.

Interoperability between EPANET and Allplan

Transfer of the plumbing system from Allplan 2018 to EPANET

As it was said before, EPANET is a 2D modeling software and it does not support IFC files, so following the

workflow 3.2 with a IFC 4 file was not possible. However, as in the case of the Revit to EPANET importation,

the Allplan plumbing system was exported to an AutoCad file, so that the program EPACAD could create

an EPANET file. As a result, the plumbing system modelled in Allplan was opened in EPANET. All the

plumbing net was correctly modelled. However, some pipes were correctly identified as pipes, while

others were created with many junctions, which makes the model less accurate. Also, the pipe diameter

and roughness assigned in EPANET was not the correct one. However, in this case all the junctions were

connected by pipes, which is different than in the case of the Revit importation to EPANET where pipes

were not connected, and a lot of information was lost.

Interoperability between Plaexos and Allplan 2018

Transfer of the architecture, structure and plumbing system from Allplan 2018 to Plexos using IFC 4

The interoperability between Allplan and Plexos was evaluated using IFC 4 according to workflow 3.3. The

model imported was very accurate. All the elements were created in the importation and they had no

inconsistencies between the original and the imported model. The height elevations were correctly

imported, and levels were correctly created. This presented no interoperability problems related to

geometry. However, objects imported to Plexos does not have any attribute assigned. In the case of the

plumbing system, all the pipes were successfully imported and identified as IFCBuildingElementProxy.

Conclusions

According to the workflows created in the methodology of this research it was possible to evaluate how

was the information between construction models transferred and which limitations could a construction

project face when data transfer was made. So, after analyzing the results obtained it is possible to

conclude that interoperability is still an issue in the IFC 4. Several differences between the original and the

imported models were observed, meaning more time for checking and correcting inaccuracies each time

a model would be exported. However, when using the IFC 4, some information was still conserved, so this

would represent less time than modelling again the project. The academia, industry and software vendors

should work together to mitigate the interoperability problem among BIM construction programs.

In general, there were some elements ignored during data transfer, but the ones imported were correct

in terms of geometry and location. However, there were observed a lot of problems in the intersection of

16

elements and among joins. Not being able to import the grids represents a limitation in relation to data

exchange between models.

In the case of Revit, it is possible to conclude that the IFC 4 Reference View is much more accurate than

the IFC Design Transfer View. Also, the interoperability problems among the Allplan, SAP and Plexos

exportation were all similar. This means that the problem is related to the exportation from Revit to the

IFC file, not in the importation. Also, there was a limitation associated with Revit families, because

different programs had a different way of representing elements, so it was not possible to represent the

elements the same as they were in the original model.

Compared to Revit, Allplan exported more accurate the IFC models. When exporting the model from

Allplan to SAP and Plexos all the elements were created and there were much less inaccuracies than in

the Revit exportations. So it could be concluded that Allplan is more accurate when exporting the model

to an IFC file. Also, in the case of the Allplan to Revit exportation the loss of information was complete.

This means that in construction projects, using both programs would represent a very big limitation in

terms of data transferring. Lastly, not being able to export the model from Allplan 2018 to Revit 2019,

only to Revit 2018 is another limitation.

In the case of SAP 2000, although it was possible to import and the geometry, modelling all the

intersections from the center of elements represented a limitation, because this is not correct in all the

cases. Element connectivity problems is also a very important limitation because if elements are separated

the structural modelling is not correct. To correct this problem the user would have to draw again all the

elements, because SAP does not let the user manually stretch or connect elements.

Although it was possible to transfer the data from Allplan and Revit to EPANET, this program is not a 3-

dimensional modelling software and this could represent a limitation in data transferring during a BIM

project. It was not possible to export EPANET data. Besides this, there was a lot of information loss during

the EPANET importation from Revit and Allplan. It was observed that data was better transferred in the

Allplan case. However, in both cases it was very important to check all the model imported because

inaccuracies were a lot.

Plexos, as it is a recent BIM program it is possible to conclude that the data exchange when importing

models from Revit and Allplan was very accurate. In the case of the Revit importation the same

interoperability problems were observed as in the Revit to Allplan case. So it is possible to conclude that

Plexos imported correctly the IFC file. In the other hand, when importing the model from Allplan to Plexos

the data exchange was perfect, and no element was ignored. Finally, since the most accurate

configuration for exporting Revit models was the IFC Reference View, not being able to import the model

to Plexos using this configuration reduces the interoperability between Revit and Plexos.

This research also has some limitations. Since it was only a four-story building with concrete rectangular

sections, other projects with other characteristics could have different results. Also, using different BIM

programs could have different results depending on the software vendors of each BIM program.

Evaluating the interoperability between more BIM programs using different case studies can help to

determine how is the industry in terms of interoperability. Also, other limitation of this research was that

the only format used to exchange information was the IFC. This research could also be done to evaluate

the interoperability of BIM programs using other format for data exchange. This could be done using an

open format or closed data exchange.

17

Bibliography

Autodesk.com (2018) Main website of Autodesk. http://www.autodesk.com/. Accessed 10.14.2018

Björk, B. C., & Penttilä, H. (1989). A scenario for the development and implementation of a building product model standard. Advances in Engineering Software (1978),11(4). https://doi.org/10.1016/0141-1195(89)90049-1

Bloor M, Owen J (1995). Product data exchange. UCL Press, London

buildingSMART.com (2018) Main website of buildingSMART. http://www.buildingsmart.com/. Accessed 10.14.2018

Chen, D., & Gehrig, G. B. (2011). Implementing Building Information Modeling in construction engineering curricula. ASEE Annual Conference and Exposition, Conference Proceedings. Retrieved from http://www.scopus.com/inward/record.url?eid=2-s2.0-80051945892&partnerID=tZOtx3y1

Eastman, C. M., Bond, A. H., & Chase, S. C. (1991). A formal approach for product model information. Research in Engineering Design, 2(2), 65–80. https://doi.org/10.1007/BF01579252

Gallaher, M. P., O’Connor, A. C., Dettbarn, Jr., J. L., & Gilday, L. T. (2004). Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry. https://doi.org/10.6028/NIST.GCR.04-867

Garber, R (2014). “BIM design”. Chichester: John Wiley and Sons Ltd, pp.28-33

Goedert, J., & Meadati, P. (2008). Integrating Construction Process Documentation into Building Information Modeling. Journal of Construction Engineering and Management, 134(7), 509–516. https://doi.org/10.1061/(ASCE)0733-9364(2008)134:7(509)

Gudgel J, editor. (2007) “Interoperability in the Construction Industry”. Smart Market Report. Mc Graw Hill Construction

Kiviniemi, A. (2008). IFC Certification process and data exchange problems. In Proceedings of the 2008 ECPPM Conference. Presented at the Proceedings of the 2008 ECPPM Conference, EWork and EBusiness in Architecture, 517–522. https://doi.org/10.1201/9780203883327.ch57

Kiviniemi, A., Tarandi, V., Karlshøj, J., Bell, H., & Karud, O. J. (2008). Review of the Development and Implementation of IFC compatible BIM. Erabuild: Review of the Development and Implementation of IFC Compatible BIM, 126.

Laakso, M., & Kiviniemi, A. (2012). The IFC standard - A review of history, development, and standardization. Journal of Information Technology in Construction (ITcon), 17(05), 134–161. Retrieved from http://www.itcon.org/2012/9

Liebich, T. (2010). Unveiling IFC2x4 - The next generation of OPENBIM. Proceedings of CIB W78 Conference; 27th International Conference Cairo, Egypt, (16–18 November), 124–131.

Stangeland, B. K. (2009). buildingSMART International, (15 November). Retrieved from http://www.buildingsmart.org/

Veras X. de Andrade, M. L., & Coeli Ruschel, R. (2009). Interoperabilidade Entre Archicad E Revit Por Meio Do Formato Ifc. IV TIC Rio de Janeiro, RJ, Brasil, (1).

Young, N. W., Jones, S. A., & Bernstein, H. M. (2007). Interoperability in the Construction Industry 2007. McGraw Hill Construction SmartMarket Report, 36.

Yousefzadeh, S., Spillane, J. P., Lamont, L., Mcfadden, J., & Lim, J. P. B. (2015). Building Information Modelling (Bim) Software Interoperability: a Review of the Construction Sector, 711–720.