Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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.