Architectural Masters Dissertation by Victoria “IVA” Ikede

MA Architectural Design

INVESTIGATING SETBACKS TO EFFECTIVE DESIGN COMMUNICATION A STUDY ON INFORMATION EXCHANGE IN DESIGN COLLABORATION USING BIM TOOLS.

A .V. I Akpezi V Ikede 160244203

arc 6988 Architectural Dissertation MA Architectural Design

Sheffield

school of architecture

September 2017

INVESTIGATING SETBACKS TO EFFECTIVE DESIGN COMMUNICATION A Study On Information Exchange In Design Collaboration Using BIM Tools

A .V. I Akpezi V Ikede 160244203 arc 6988 Written Dissertation MA Architectural Design

Sheffield

school of architecture

September 2017

Akpezi Ikede 160244203

This document has been produced and published by the University of Sheffield School of Architecture. All rights reserved by the University of Sheffield. No part of this publication may be reproduced, stored in a retrieval system, copied or transmitted without the prior written consent of the publisher except that the material may be photocopied for educational purposes without permission from the publisher.

Faculties of Social Sciences, Sheffield School of Architecture, The University of Sheffield, Arts Tower, Western Bank, Sheffield, S10 2TN, UK. www.shef.ac.uk/architecture ARC6988 Masters in Architectural Design Dissertation 2016/17 Session

Akpezi Victoria Ikede Student No: 160244203 Email: avikede1@sheffield.ac.uk Project supervisor: Dr Mark Meagher - MArch (Harvard), PhD (EPFL) Completed: 4th of September 2017

MA Architectural Design

There is the represented world and the representing world. It is the tools we use to represent our world that allow us to explore the unreachable. It is things that make us smart.

- Things that make us smart Norman (1993).

Akpezi Ikede 160244203

Acknowledgements I would like to thank and acknowledge:

God, for hope and love, The Niger Delta Development Commission for sponsoring my education, Dr Mark Meagher for his dedicated supervision and mentorship throughout the research process, Artists at Freepik.com for using their vector graphics in my designs.

MA Architectural Design

Preface Architectural computer tools that have become deeply ingrained in the way designs are produced, studied and analysed. In some cases, the software has become denotative of specific aspects of architecture (e.g. AutoCAD is synonymous with 2D drafting and detailing). In the early stages of this research, the idea for research into data exchange within the most widely used architectural CAD software in schools and professional settings was discussed among my peers about how file exchanges occur. However, I received feedback burdened with scepticism on how ‘architectural’ this mode of inquiry was in real terms. Reasons for this, I presume, are because the issues that exist within the tools we use for architectural drawings every day appear to be a subject perhaps best left to their creators. While this dissertation is not an investigation into the state of tool-based or computational research in architecture; I find it necessary to say at this point that perhaps the reason why architecture is lagging behind in computational research in comparison with other process-to-product professions stems from this kind of indifference towards the subject. This research is important to me because I personally have lost valuable time in CAD design phases of school and office projects trying to fix errors in my model due to different software formats. This is a common challenge faced by most architects as a result of the different optimised capacities of individual software platforms, making it a necessity to use more than one software platform in the accurate delivery of design. Interoperability challenges exist and understanding them should be a concern to any architect who uses CAD tools to deliver ideas. Perhaps by first acknowledging the import of these problems, we can propose lasting solutions. Before this research investigation, I had never explored the “back-end” of the computer applications I used to generate beautiful renderings and detailed drawings. While it might seem a very technical undertaking, I encourage the first timer to the topic of BIM and exchange standards to approach it with patience. I firmly believe that if I was able to get a grasp of it in the short time of conducting this research, there lies hope for any other patient reader.

Akpezi Ikede 160244203

ABSTRACT The implementation of BIM (Building Information Modelling) as a standard process for effective collaborative practice in the AEC-FM (Architecture, Engineering, Construction and Facilities Management) industries has increased the efficiency of information organisation and sharing amongst industry stakeholders. However, challenges involving software interoperability in BIM has generated interest in current research endeavours. These challenges are a result of differences in file formats from the commercial design tools used by different industry stakeholders. The Industry Foundation Classes(IFC) were created to act as a central translator in the management of BIM models. It is a platform agnostic open file format that is not controlled by a single software vendor or group of vendors. The IFC data model, however, is limited in its ability to preserve building data significance and meaning during an exchange process.

The purpose of this study is to examine information exchange using BIM tools with the IFC standard, identifying the changes to building information as it is shared among professionals. A series of exchanges using IFC certified BIM tools and architectural building components were done to assess the ability of the IFC to accurately preserve information during file transfer. Overall, the results are presented to show that limitations with IFC file transfer have greater significance beyond mere technicalities. A guide for how collaboration can be improved as an outcome of this study was presented in conclusion.

Keywords: Collaboration, Design Communication, IFC, Exchange, Interoperability.

MA Architectural Design

Table of Contents Abstract Glossary List Of Figures List Of Tables

8 10 11 11

CHAPTER 1: INTRODUCTION 1.0 BACKGROUND OF STUDY 1.1 STATEMENT OF PROBLEMS 1.2 DEFINITION OF TERMS 1.2.0 BIM - A METHOD FOR COMMUNICATION AND COLLABORATION 1.2.1 INTEROPERABILITY 1.3 PURPOSE OF STUDY 1.4 IMPORTANCE OF STUDY 1.5 RESEARCH QUESTIONS

13 13 15 16

16 17 19 19 20

CHAPTER 2: LITERATURE REVIEW 22 2.0 BIM EXCHANGE 22 2.0.1 BIM PARTICIPANTS 22 2.0.2 BIM ACTORS AND TOOLS 24 2.0.3 LEVELS OF BIM 24 2.1 TOOL INTEROPERABILITY 26 2.2 THE IFC DATA MODEL 27 2.2.1 BRIEF HISTORY OF THE IFC DEVELOPMENT 28 2.2.2 IFC IN THE ARCHITECTURAL DOMAIN 30 2.2.3 THE LIMITATIONS TO IFC IMPLEMENTATION 31 2.3 THE IFC TYPOLOGY 31 2.4 INFORMATION REPRESENTATIONS USING THE IFC 35 2.4.1 GEOMETRIC INFORMATION 35 2.4.2 SEMANTIC INFORMATION 35 2.4.3 TOPOLOGICAL INFORMATION 36 2.5. IFC CERTIFICATION 36 2.5.1 MODEL VIEW DEFINITIONS 36 2.5.2 INFORMATION DELIVERY MANUALS 37

2.6 CHECKING FOR ERRORS WITH THE IFC 39 2.6.1 IFC MODEL ERRORS 39 2.6.2 METHODS FOR ERROR CHECKS USING THE IFC 39 2.6.2.1 DATA TRIP TESTING 40 2.6.3 RESULTS FROM PREVIOUS STUDIES 42 CHAPTER 3: METHODOLOGY 45 3.1 EXCHANGE SCENARIO 46 3.2 EXCHANGE TESTS 47 3.3.1 SOFTWARE TOOLS 49 3.3.2 BIM DESIGN TOOLS 49 3.1.3 IFC TOOLS 49 3.4 TEST CASES 51 3.5 TEST SUMMARY 54 CHAPTER 4: RESULTS 57 RESULT TABLES 59 4.1 ANALYSIS OF RESULTS 72 4.1.1 IMPORT AND EXPORT SUCCESS 72 4.1.2 DIMENSIONS AND POSITION 73 4.1.3 MATERIALS 73 4.1.4 LABELS AND DESCRIPTIONS 74 4.1.5 FUNCTION AND PHASE CHANGE 74 4.1.6 VISUAL TRANSLATION OF OBJECTS 74 4.1.7 GEOMETRIC REPRESENTATION 75 4.1.8 PRESERVATION OF GUID 75 4.2 LESSONS LEARNT 77 CHAPTER 6: CONCLUSION 80 6.1 RECOMMENDATIONS FOR FUTURE RESEARCH 80 REFERENCES 83 APPENDIX 87

Akpezi Ikede 160244203 GLOSSARY abbreviations 2D, 3D – Two and Three - dimensional AEC-FM- Architecture/Engineering/Construction and Facilities Management BIM – Building Information Model/ Modelling B-rep – Boundary Representation BuildingSMART International- The renamed industry alliance for interoperability. BLIS - Building Lifecycle Interoperable Software DLL – Dynamic Link Library EXPRESS – Coding Language for IFC files and STEP GUID - Globally Unique ID. A unique entity identifier across applications. IAI – Industry Alliance for Interoperability, a consortium for interoperability development and management of exchange standards. ISO – International Standards Organization MVD – Model View Definition MEP - Mechanical, Electrical and Plumbing SIO - Solibri IFC Optimizer SMC – Solibri Model Checker SMV- Solibri Model Viewer STEP – Standard for the Exchange of Product Model Data

TERMS Attribute – unit of information within an entity. Entity- Class of information defined by common attributes. Instance – occurrence of an entity. Object – A distinctive piece in a building model made up of several entities. Type - A basic Information construct derived from a selection of entities. Schema - The organization or structure for a database

MA Architectural Design

LIST OF FIGURES

Fig. 19 Categories of file data trips in IFC

Fig. 1 Visual Summary of the

conformance testing (buildingSMART

International, 2017f)

project(Author's Own)

Fig. 20 Exchange scenario between two

Fig. 2 Information sharing in architectural

design (Author's Own)

architectural firms(Author's Own)

Fig. 3 Overview of research spheres in

Fig. 21 Solibri Comparison Report for Test Case X4

collaborative design (Achten and

Beetz, 2009)

users(Solihin et al., 2015)

Fig. 22 Tools used for experiments(Author's Own)

Fig. 23 Exchange workflow for the experiments

Fig. 4 Source of errors are black-boxes to end

(Solibri Model Checker, 2017)

(Author's Own)

Fig. 5 An overview of Interoperability research

Fig. 24 Direction of exchange for the first set of tests

interests among students and professionals

(Bercerik-Gerber and Kensek, 2010)

Fig. 25 Direction of exchange for Revit models

(Author's Own)

Fig. 6 The impact of incorrect building information

transfer through file exchange (Google

Fig. 26 Direction of exchange for ArchiCAD models

Images - error due to construction)

(Kostoff,1992)

(Author's Own)

Fig. 27 Pure round trip

Fig. 7 BIM exists where there is Collaboration

(Author's Own)

Fig. 8 Illustration showing BIM Phases with

Fig. 28 Some entities were not processed

Tools Used, Information exchanged and

Stakeholders involved(Author's Illustration

Fig. 29 Definition of IFC terms used in the discussion

based on Kensek,2014)

(NIST IFC Analyser Report,2017)

(Author's Own)

Fig. 9 Signifiance of building information

Fig. 30 Revit Stairs before and After Export

representations to different project

stakeholders(Authors Own)

Fig. 31 Total Number of entities (Author's Own)

Fig. 10 The four levels of BIM (Kensek, 2014 and

Fig. 32 Possibilities enabled by IFC (Author's Own)

Fig. 33 Solibri Results grouping (Solibri Model

Muller et al. 2017)

(Author's Own)

Fig. 11 Illustration of collaborative exchange

Fig. 34 Solibri IFC Optimizer Results (Author's Own) 79

without an open standard(Author's Own) 28

Checker,2017)

Fig. 12 History of the IFC since its early inception

Fig. 35 IFC transfer between Architects and other

(Amor, 2015, buildingSMART 2017b,

Laakso and Kinvieniemi, 2012)

Fig. 13 Illustration of collaborative exchange using

consultants(Author's Own)

the IFC open standard(Author's Own) 30

LIST OF TABLES

Fig. 14 Referencing occurs downwards in the IFC

Table 1 Overview of results from past experiments

Table 2 Errors identified with IFC after exchange

schema(Laakso and Kinvieniemi, 2012) 32

process

Table 3 IFC Test Cases

Fig. 16 The parts of the IFC text file for Hello_wall

Table 4 Revit Test Cases

Table 5 ArchiCAD Test Cases

Table 6 Import and Export Results

Fig. 15 The architecture of the IFC schema

(buildingSMART International,2015) (buildingSMART, 2017c)

33 34

Fig. 17 Information representation using the IFC

Table 7 Results from IFC models

60 - 63

Fig. 18 Diagram illustrating the types of

Table 8 Results from Revit Models

64 - 68

descriptions available in an Information

Table 9 Results from ArchiCAD Models

Delivery Manual(Kinvieniemi,2006)

(Zlatanova, No date)

Akpezi Ikede 160244203

INFORMATION EXCHANGE LITERATURE REVIEW METHODOLOGY BIM IFC

EXPERIMENTS ERROR CHECKS RESULTS

CONCLUSION

DESIGN COLLABORATION

Fig. 1 Visual Summary of the project (Author's own)

MA Architectural Design

CHAPTER 1 INTRODUCTION A building should meet all the requirements of structural stability, aesthetics, environmental comfort and economic efficiency. Computer software has become the primary tools for accomplishing these goals in the 21st century. They enable creativity in design production, as faster automated systems have replaced timedemanding manual tasks of the past. Complexity in design will require precise information detail and an effective systematic coordination of tasks. In most cases, a single designer will not possess the knowledge necessary to meet all the demands of a project, thus making collaboration a necessity in design. Collaboration requires effective communication and information exchange. Accurate data transfer is a crucial part of the exchange process with computer tools. Preservation of accurate building information is therefore needed during such processes for the stakeholders involved to work efficiently. Developments in information technology have encouraged the ambitions of designers to explore more complicated ideas and building forms. Additionally, digital tools favour the current global concern for sustainability by enabling energy analysis at preliminary design stages (Watson, 2011).

1.0

BACKGROUND OF STUDY

Multidisciplinary collaboration is required in the realisation of building projects from its conceptual stages until the end of its life-cycle at demolition. In the AEC-FM (Architecture, Engineering, Construction and Facilities Management) industries, drawings function beyond their aesthetic value and help to convey significance and meaning in the form of detailed building models. Building drawings contain necessary information required at the different phases of a project. In most cases, the drawings are checked for errors periodically at each level of completion before more information is added. This study will be focused on investigating the setbacks to effective design collaboration by exploring design representations in modelling through the computer tools used for information exchange. According to Achten and Beetz (2009), this implies research into all the formal approaches to making collaborative design models. Research into collaborative modelling deals with topics on design, information and knowledge representations. Information modelling deals with studies on visual and non-visual information that are generated exchanged or presented during collaborative design.

Akpezi Ikede 160244203

Manual file Sharing

Sketches

Client's Brief

Digital file Sharing

Documentation and design planning Excel

Site surveys

Spreadsheets

Printed

Site Analyses

Drawings PDFs

Presentations 3D Visualizations

Space Program definitions Specifications

2D Drawings

Architectural Model Energy Analysis

Structural Model Services Coordination

Models from other disciplines MEP Design Delivery

Fig. 2 Information sharing in architectural design (Author's own)

MA Architectural Design Collaboration in this study refers to the exchange of information between building design participants with a

Fig. 3 Overview of research spheres in collaborative design (Achten and Beetz, 2009)

shared goal of achieving a completed building project within the shortest time and in the most efficient ways possible. Exchange addressed in this study refers only to software communication, and does not deal with the other means architects and other industry professionals use for information transfer.

1.1 STATEMENT OF PROBLEMS Solihin et al. (2015) presented an illustration of a typical file exchange workflow, which presents the major part of the exchange process as a black box to its users as illustrated in Fig 4. The black-boxes in the diagram shows the actions that contribute to the quality of a model after it has moved from one platform to another. The hidden nature of these error generating points creates difficulties for the designer at the receiving end of a design workflow to make useful corrections to the degraded model.

Export

Software internal modelling capability Sender

Import

IFC file

Importing software mapping to the IFC.

Sources of error

Receiver

Fig. 4 Source of errors are black-boxes to end users (Solihin et al. 2015)

Akpezi Ikede 160244203 1.2 DEFINITION OF TERMS 1.2.0 BIM - A METHOD FOR COMMUNICATION AND COLLABORATION A building model is used by designers in the dialogue between built and unbuilt realities. Building Information Modelling or BIM, as it is commonly referred to among industry professionals, can be described as the creation of a shared product and process data model which enables precise decision making in a project throughout its lifecycle; from inception to demolition (Laakso and Kiviniemi, 2012; National Institute of Building Sciences (NIBS), 2014). Berlo et al. (2012) define the data model as an abstract model that documents and organises business data for communication between team members. It can, therefore, be considered the core entity for collaboration in modern-day design practices. BIM has risen to the forefront as the preferred platform for information sharing among professionals in recent times (Kensek, 2014). This is a result of the degree of accuracy that can be achieved through the computational tools which are now representative of BIM. Previously, methods used for file sharing in collaborative practice were manual and thus extremely tedious and time-consuming. The confusion arising from a reliance on too many individuals made such practices highly prone to error, misrepresentation and low-quality assurance. The underlying reasons behind the push for computational BIM workflows in design were to facilitate robust data exchange in all phases of complex, large-scale projects (Watson, 2011). BIM is now considered a standard for design practices in most countries (Ciribini et al. 2016).

Some relevant definitions for discussing BIM tools are explained below: •

Software vendor: The creators of proprietary computer tools for building design communication are

known as software vendors. They are responsible for releasing updated versions of their products to meet market demands and satisfy requirements for correct mapping of the internal data structure of their BIM tool with exchange standards. •

Authoring Software: This describes the specific tool in which a model is first defined. It is the first

software with which a BIM stakeholder adds a specific dataset for the first time, and the new data is usually stored in the authoring software’s native format. The native formats of specific BIM software are defined by software vendors and are referred to as proprietary formats in this paper.

MA Architectural Design 1.2.1 INTEROPERABILITY The implementation of BIM as a standard process for collaborative practice in the AEC-FM industries has met with challenges involving software interoperability resulting from differing file formats from design software used for information sharing among project stakeholders. Kensek (2014) defines interoperability as the effective transfer of data across domains and platforms. Full interoperability implies being able to precisely define methods of realising the model as a true construct of collaboration and contract (Ciribini et al. 2016).

Fig. 5 An overview of Interoperability research interests among students and professionals. (Becerik-Gerber and Kensek, 2010) Although there are several methods for achieving interoperability in AEC-FM collaboration, the subject of this study will be tool interoperability in BIM. This can be defined as the ability for a group of designers working concurrently on a BIM project with heterogeneous software to exchange information accurately without loss of model data, or data significance and meaning. An estimated 15.8 million dollars is lost annually in U.S capital facilities due to inefficient interoperability according to a United States study conducted by NIST (US National Institute of Standards and Technology) in 2002. These costs make up to 1-2% of the industryâ&#x20AC;&#x2122;s annual revenue (Gallaher et al., 2004).

The Industry Foundation Classes(IFC) have been created as a solution to deal with challenges in software interoperability for large scale collaborative practices. The IFC is a vendor neutral, platform agnostic file format, designed to function as a universally readable language with all industry software. However, research has shown that models exchanged using the IFC format mutate as they are exchanged from one design platform to the next. In many cases, parts of building models are completely lost or redefined.

Akpezi Ikede 160244203

EXPORT

IMPORT

AUTHORING SOFTWARE EXCHANGE STANDARD

EDITING SOFTWARE

FINAL PRODUCT

- Red lines indicate sources of error Fig. 6 The impact of incorrect building information transfer through file exchange (Author's illustration with Google Images - errors due to construction) 18

MA Architectural Design 1.3 PURPOSE OF STUDY This study is aimed at investigating how model mutations occur in an exchange process using the IFC standard. This will be done by analysing IFC models using automated analytical tools and manual methods. A simulated work-flow of exchange with BIM tools and the IFC standard will be used to identify the errors that occur in the exchange of specific test models. The specific objectives of this study are to identify: 1. The significance of model data to the levels of information exchanged at the different stages of BIM collaboration. 2. The current data exchange standards, as well as the problems which are encountered in using them, and existing solutions currently aimed at addressing them. 3. The limitations of these solutions identified in (2) above.

1.4 IMPORTANCE OF STUDY Building Information models can be easily manipulated in the design phase. According to Ciribini et al. (2016), BIM can enhance the way participants work by introducing preliminary error checks and performance analysis in the earlier stages of the project. Assurance and quality control can be ensured through methods of model validation and checking. Model validation implies ensuring that the data in the original file is there after it has been exported, whereas checking implies ensuring it is the right kind of data that exists. Model quality checks help to optimise designs by identifying problems that could remain unnoticed during the different BIM levels of exchange. It also holds the potential to significantly reduce construction time because most clashes in design specifications which usually surface at the construction phase would have been dealt with at the design phase. Strict deadlines and limited resources usually do not permit project stakeholders to perform error checks on each model before it is transferred for further development. Therefore, mistakes experienced by most users of the IFC has limited its implementation in practices, restricting data transfer to server-based file sharing with documents and proprietary file formats. However, there are limitations to this method of server-based file as an alternative to the IFC, as will be discussed later in Chapter 2. Identifying the exact kind of errors that could be encountered with IFC exchange is a starting point for improvements to the IFC and thus better interoperability in collaboration.

Akpezi Ikede 160244203 1.5 RESEARCH QUESTIONS The IFC has been established as an exchange standard for BIM collaboration in the AEC-FM industries. However, errors due to file exchange are still a setback to IFC implementation thus limiting software interoperability and efficient collaboration in design. The questions this study aims to address are:

•

What kind of mutations happens to models during IFC exchange?

•

How significant is the information that is lost?

•

What lessons can be learned for improving design communication with the IFC?

The question will be answered by first identifying the errors to be expected and solutions existing based on previous research. Further experiments will then be carried out to precisely determine the kind of errors that occur in models during model exchange and their relative significance to design professionals during collaboration.

MA Architectural Design

Akpezi Ikede 160244203

CHAPTER 2 2.0 BIM EXCHANGE According to Race (2012), BIM as a tangible entity does not exist. He defines BIM as a state of mind of collaboration whose current reliance has become technology. In the most basic sense, BIM began to exist in architecture as soon as a building drawing communicating some information was exchanged between two people to get built (Race, 2012 p. 13).

As drafting in large-scale collaborative and multidisciplinary design efforts have moved from pen and paper to computer-aided design (CAD), designers need to understand how to communicate information with computer tools. Communication of ideas in this method of design practice requires software interoperability for the exchange of project files to function optimally. The resulting data from the export and import processes of file sharing in BIM can significantly impact the quality of the final building construction.

Fig. 7 BIM exists where there is Collaboration (Kostoff, 1992)

2.0.1 BIM PARTICIPANTS A major feat achieved in the building sector through the rapid development of information technology is the ability to be represent real life building objects in data formats on computer software. A redefinition of traditional roles became required as the process of creating buildings through BIM gained popularity (Amor et al., 2007).

MA Architectural Design

Investigating errors resulting from file exchange requires a fundamental understanding of the participants in BIM collaboration as well as the tools they use to create detailed information models at specific stages of a project. Some questions which stem from this include: •

Who is responsible for managing the modelling in BIM?

•

SUMMARY OF INFORMATION AT THE work-flows DIFFERENTof STAGES How are clients affected by theNEEDED computational BIM? OF DESIGN COLLABORATION

•

What kind of information do participants exchange?

•

What tools are used for exchange?

PRE DESIGN Revit ArchiCAD VectorWorks BricsCAD

SITE ANALYSES SOLAR STUDIES SKETCHES CONCEPT DRAWINGS/MODELS SCHEMATIC DESIGNS MASSING STUDIES FIRST PRESENTATIONS WITH CLIENT SIMPLE COST ESTIMATES

DESIGN ArchiCAD Revit Architecture/ Structure/MEP Tekla Structures VectorWorks Scia Engineer

APPROVED CONCEPT

DESIGN DEVELOPMENT 2D/3D COORDINATION SPECIFICATIONS MATERIAL PLANNING DETAILED MODELS FROM ARCHITECT, MEP AND STRUCTURES CLASH DETECTION ENERGY ANALYSES FIRE EXIT/EGRESS ANALYSIS

Clients, Architect, Engineers Project Manager

Project Manager, Architect, Engineers, Consultants

BID/BUILD Archifm.net Revit Solibri Model Checker NavisWorks Sigma Estimates Vico System

BIDDING/NEGOTIATIONS PROJECT SCHEDULING QUANTITY TAKE-OFF MATERIAL SELECTION CLASH DETECTION CONSTRUCTABILITY MODEL

Project Manager, Architect, Engineers, Consultants, Contractors, Construction Managers

AS BUILT - FM HANDOVER

OCCUPANCY

RENOVATION ASSET MANAGEMENT INVENTORY TRACKING SPACE PLANNING

Facility Manager, Owner

Fig. 8 Illustration showing BIM Phases with Tools Used, Information exchanged and Stakeholders involved(Author's Illustration based on Kensek, 2014)

Akpezi Ikede 160244203

2.0.2 BIM ACTORS AND TOOLS A BIM actor or stakeholder refers to any individual in the collaborative building process with a claim to ownership of information included in the data model. BIM stakeholders include owners, architects, contractors, structural engineers, MEP, and facility managers. The diagrams in Fig 9 and 10 presents a visual summary of BIM Stakeholders at different phases of a project, including the classes of information they are expected to provide. The way BIM is implemented in firms is dependent on the organisational structure of the particular practice. In most cases, the project manager also assumes the role of BIM manager, however, additional training may be required.

2.0.3 LEVELS OF BIM Several actors, processes, and exchanges function at the different stages of a collaborative process. Energy Analysis Geometry, Intersections Space Units Boundaries Containments

Simergy

ArchiCAD Revit

Architect Massing Dimensions Materials Space Program Architectural Naming e.g Floor, Wall, Kitchen, Living Room

Structural Engr: Plumbing Engr. Dimensions around other specified components. Space Units Space Naming e.g Toilet, Kitchen

IFC

Tekla Structures

Revit MEP

Architectâ&#x20AC;&#x2122;s Model Construction Phasing Dimensions Structural Naming e.g Slab, Load Bearing Wall Column.

Revit MEP Electrical Engr. Dimensions, Space units.

Fig. 9 Signifiance of building information representations to different project stakeholders(Author's own)

Firstly, it is necessary to identify the levels of information required at each stage.

MA Architectural Design

Sinclair (2012) describes four levels of

STAGES OF COLLABRATION SOFTWARE WHERE INTEROPERABILITY IS MOST NEEDED

BIM as discussed below: Level 0: 2D CAD Here,

data

representation

purely

geometric. Most prospective BIM users start out at this level, using BIM tools solely for visualisation and graphical representation. A building information

LEVEL 2 Holistic federated model. A unified model from which all analysis/ decisionmaking is done.

model differs from CAD in the degree of information it can share and preserve. Traditional

CAD

programs

LEVEL 2 Integrated Models from stakeholders

represent

LEVEL 1 Discipline Specific Single Models

space using geometric information, in which case, deriving valuable additional information such as energy or egress analyses

would

require

complex

LEVEL 0 Simple Geometry .

Fig. 10 The four levels of BIM (Kensek, 2014 and Muller et al., 2017)

calculations. However, a BIM model would have such information distinctly described (Khemlani, 2004).

Level 1: 2D and 3D Information Model At this level, aspects of the two-dimensional geometric model that was undefined in the previous level are added for a holistic three-dimensional view of the design. Additionally, non-geometric data such as materials and costs are included at this stage to enable other forms of analyses like quantity costing, fire rating, energy analysis, and egress analysis. Additionally, at this time, the building model is created and acted on by a single or smaller party, usually within a homogenous suite of design applications. Interoperability challenges are minimal here because proprietary software enables communication among two designers with its native file format. This stage is also sometimes referred to as lonely BIM(Sinclair, 2012) or little BIM(Berlo et al., 2012). Collaboration is limited at this level.

Akpezi Ikede 160244203

Level 2: This level calls for collaboration with all actors involved in a project. Individual actors should complete their separate data models in an integrated team at this level. Exchange of information between heterogeneous software platforms is not a necessity at this stage, depending on the actors involved. However, in most cases, this type of exchange occurs as stakeholders tend to build on information already created. For example, the structural engineerâ&#x20AC;&#x2122;s data model depends on the architectâ&#x20AC;&#x2122;s data model. Where exchange occurs between various software, it is referred to as open BIM(buildingSMART, 2016). Due to constraints evident in this type of data exchange, some BIM users have proposed that all actors use homogeneous software platforms in data creation and sharing. Nevertheless, an experiment carried out by (Berlo et al., 2012) exposed the desire in most designers to select software tools based on an assessment of the task at hand rather than an attempt to achieve perfect collaboration. The interoperability challenges present in open BIM reinforces the need for an exchange standard.

Level 3: This level entails the merging of individual models of the fragmented team into a single holistic BIM Model. Interoperability challenges are most evident at this stage of the internal data structure of most CAD tools are designed to meet market demands with little considerations on communication with other software.

2.1 TOOL INTEROPERABILITY Traditionally, the orderly arrangement of files in a cabinet, or the more common organisation of folders in a computer can be regarded as a collaborative BIM practice (Laakso and Kiviniemi, 2012). The advent of computer software abilities to create accurate digital representations of real-world building elements makes computational tools a determining factor for successful BIM collaboration in the AEC- FM industries. The industry leaders of commercial BIM software packages include; Autodesk, owners of Revit and AutoCAD, Nemetschek, Tekla and Bentley (Mhmad Bayyari, 2015).

MA Architectural Design

Kensek, (2014) also identifies two major approaches geared towards facilitating effective interoperable exchange in current research: â&#x20AC;˘

A single data format that can link multiple formats through a common open standard, and,

â&#x20AC;˘

A single central model server or linking multiple servers serving as a model information

repository and accessible to clients and stakeholders at multiple entry points. The central server approach involves the use of a central data repository, which includes shared files in project folders for design participants working with homogeneous tools. This allows for part-work from each collaborator, saving time in developing fully detailed models on one end, by developing just the necessary bits and then passing it on to the next stakeholder (Berlo et al., 2012). However, errors inefficient process and workflow definition, as well as lapses in editing time (resulting from two collaborators affecting a change on a model at the same time) in most practices reduces the effectiveness of this approach. BIM models contain detailed attributes with representations that can be transferred from one model to another using an open exchange format. The IFC (Industry Foundation Class) has become the standard that presently functions as the most efficient format for information exchange and complies with ISO 16739(BuildingSMART, 2016).

2.2 THE IFC DATA MODEL Without a common exchange standard, each software vendor must create direct translators to share data back and forth with each software used by BIM collaborators as illustrated in Fig 11. However, the IFC open exchange standard allows a direct mapping from individual applications and serves the purpose of a central translator for all the information exchanged as described in Fig 13. The open standard allows the only data mapping required in BIM exchange to be between the software and the standard itself (Berlo et al., 2012). The IFC is a free, open source, vendor neutral file format for exchange. IFCs are typically encoded in three file formats namely the Ifc, ifcXML (the XML translation of the STEP), and ifczip (compressed format of either of the previous definitions). The IFC is the most recent and widely implemented standard for openBIM exchange and forms the basis for this study (Kensek, 2014).

Akpezi Ikede 160244203

Fig. 11 Illustration of collaborative exchange without an open standard(Author's Own)

2.2.1 BRIEF HISTORY OF THE IFC DEVELOPMENT The IFC is an object based data model developed by the Industry Alliance for Interoperability(IAI), a global consortium of companies created in 1996 to support interoperability (Khemlani, 2004). The IAI consortium was renamed to buildingSMART in 2006. The IFC was defined by the IAI Model Support Group (IAI-MSG) now known as buildingSMART - MSG. The Model Support Group is comprised of six members located in different parts of the world(Khemlani, 2004). IFCs are an end-product of an evolution of exchange formats. Before the development of the IFC, exchange formats included the IGES and .dxf for surface models consisting of points, lines and planar surfaces, with later developments of the .dwg and sat for solid models. The IGES (Initial Graphics Exchange Specification) was published in 1980 at the early development stage for an open exchange standard between CAD systems(Laakso and Kiviniemi, 2012). The .dxf (drawing exchange format) was also similarly created by Autodesk in the 1980s for data exchange between AutoCAD and other CAD software. However, both models were surface based and could not represent solid-based geometry.The IGES could only work for a limited number of proprietary

MA Architectural Design

applications before development efforts stopped, as efforts toward implementing an exchange standard had not been widely embraced at the time(Laakso and Kiviniemi, 2012). The .sat, .stl, .obj and .dwg are other examples of widely used format that supports the exchange of solid models but can only facilitate interoperability within a limited suite of applications. These object based formats enable exchange with more complex parametric design tools like Rhino3D (Ryu, Lee and Choi, 2016).

Fig. 12 illustrates the development of the IFC model since its inception. A detailed account of the IFC since discussion for its release first started in the early 1990â&#x20AC;&#x2122;s has been given by Laakso and Kiviniemi (2012).The IFC specification is developed and maintained by buildingSMART International as its data standard since it is accepted as ISO 16739. (Khemlani, 2004; BuildingSMART, 2016). The latest version of IFC is IFC4, which was released by building SMART in March 2013 (Amor, 2015).

1950s

The search for ad-hoc solutions to information exchange

1980s Could not represent solid-based geometry

1970s

IGES

DXF

Development discontinued

IFC 2 X

IFC 2.0

Surface Models

Solid modelling formats

.DWG

Developments on the IFC

1999

IFC1.5 IFC1.5.1

SAT does not retain semantic and relational information

IFC1.0

IFC 2 X 2

IFC 2 X 2 Add 1

2006

IFC 2 X 3

IFC 4

2015

... IFC4 ADD 1

IFC 2 X 3 TC1

2013

Fig. 12 History of the IFC since its early inception (Amor, 2015; buildingSMART, 2017b; Laakso & Kiviniemi, 2012)

Akpezi Ikede 160244203

Other widely used exchange formats include the XML (Extensible Markup Language)which can be integrated into other disciplines such as the gbXML(Green building XML) designed for interoperability between energy analysis programs and BIM authoring platforms, and aecXML, ifcXML and other XML based schemas(Kensek,2014).

Fig. 13 Illustration of collaborative exchange using the IFC open standard (Author's own)

2.2.2 IFC IN THE ARCHITECTURAL DOMAIN Automated BIM Model validation which can be achieved using the IFC is useful to design stakeholders who need to verify the correctness of information specified, government officials who require models for public projects and by building regulation authorities who need to ensure building compliance. Interoperability research is geared towards improving the information model validation process. The IFC includes architecture, building services, and structural models in exchange requirement coordination delivered as a subset of the IFC schema Model view definition. 'Architecture has been included in the IFC specification from its first release, and therefore it can be seen as the most complete and accurate part of IFC based BIM (Pazlar & Turk, 2008)'. 30

MA Architectural Design

2.2.3 THE LIMITATIONS TO IFC IMPLEMENTATION Research shows that one of the major barriers to IFC Implementation in current BIM practice is file size due to over-representation of entities as evidenced in a robust round trip experiment carried out by Pazlar and Turk(2008). The unpredictability of outputs from IFC transfer so far has discouraged many designers from using the model. While the buildingSMART-MSG (Model Support Group) is responsible for the accuracy and usability of the IFC model, the buildingSMART-ISG (Implementation Support Group) takes the responsibility of ensuring the exchange standard is implemented in BIM practices.

2.3 THE IFC TYPOLOGY The IFC was created based on ideas from the STEP (Standard for the Exchange of Product Model data) format used in manufacturing industries (Amor, 2008). Similar to STEP, it has been modelled using the EXPRESS longform modelling language. The IFC shares common definitions with the STEP in the EXPRESS language such as WHERE clauses. There are four main layers in the IFC schema’s architecture namely: Resource Layer: This contains entities with generic information unrelated to buildings such as geometry, material, quantity, measurements, cost, date and time. It is the lowest level in the schema hierarchy, and its information is used to describe objects in the layers above it. In the IFC schema, referencing can only occur downwards, thus ‘the resource layer must be independent and reference no classes above it (Laakso and Kinvieniemi, 2012)’. Several resource definitions were derived from the STEP standard. Core Layer: The kernel and extension modules make up the core layer. It is the most general layer within the architecture of the IFC schema and provides the basic structure for further specialisations in phase specific models. The Kernel determines the model breakdown describing concepts such as objects, property, relationships, type definitions, attributes and roles. The core extensions describe specialisations of the classes defined in the kernel. They describe control, product, process and resource concepts. Product concepts include space, site, annotation and building elements. The core layer describes common concepts from which entities in the shared element and domain specific layer are referenced. 31

Akpezi Ikede 160244203

Interoperability Layer: This level provides descriptions for entity information shared among other AEC-FM applications and provides the basis for interoperability between shared data across heterogeneous domains. Domain Layer: This is the highest level of the IFC schema architecture, and it can reference all the other layers downwards. It describes concepts for software and domain specific entities such as architecture, Mechanical, Electrical and Plumbing (MEP), structural engineering and so on.

(Khemlani, 2004; Laakso and Kiviniemi, 2012; buildingSMART International, 2015)

Fig 14 Referencing occurs downwards in the schema( Laakso and Kinvieniemi,2012)

MA Architectural Design

Fig. 15 The architecture of the IFC schema (buildingSMART International, 2015)

Akpezi Ikede 160244203 Header Section

Data Section

Project Structure Definition

Window Definition

Project Structure Hierarchy

Opening

Material Definition

Alphanumeric property and quantity information

Wall Definition

Fig. 16 The parts of the IFC text file for Hello_wall (buildingSMART 2017)

MA Architectural Design

2.4 INFORMATION REPRESENTATIONS USING THE IFC There are three classifications of information that can be extracted from an IFC model namely:

2.4.1 Geometric Information: In BIM, geometries are made of points, lines, curves, loops and polygons which can be represented in the IFC schema. Geometries in a BIM model possess a coordinate on the global axis also known as a geo-reference (Isikdag et al. 2013), and a GUID (Globally Unique Identifier). The significant differentiation between a traditional CAD model and a 3D BIM is in the level of data its geometry carries. Geometric boundaries are crucial for energy analysis using the IFC as they define spatial enclosures which form the basis for space energy performance. Intersecting geometries can lead to inaccurate results or errors reporting as false positives due to duplication of elements at the points of intersection (Ladenhauf et al., 2016). Geometric inputs include building elements and spaces while outputs include boundary parts, such as the B-rep (Boundary representation) which are represented as looped polygons.

2.4.2 Semantic Information: Kensek (2014) defines semantics as â&#x20AC;&#x2DC;the identity of a collection of dataâ&#x20AC;&#x2122;. Typically, a BIM model carries volumetric and parametric information. However, a BIM like the IFC can also contain significant semantic information (Isikdag et al. 2013). Tangible building elements like walls, windows, and doors, are represented in the IFC text format as semantic representations like IfcWall, IfcWindow and IfcDoor. The semantic detailing of objects makes it possible for edits in the text format to translate into three-dimensional geometry when viewed with an IFC file viewer such as the Solibri Model Viewer. Non-tangible elements of a building can also be represented in the IFC semantically such as IfcApplication. Semantic information in BIM can also refer to the generic naming of spaces, building stories, floor levels, and helps give a precise definition of what an object represents. It is crucial for the assessment of IFC data quality(Lee et al., 2011).

Akpezi Ikede 160244203

2.4.3 Topological Information: The concept of building topology in BIM stems from the concept where every point in 3D Euclidean space belongs to exactly one unique building part, whether interior or exterior (Paul and Borrmann, 2009). A topology defines the spatial relationship between two points or objects in building models. Researchers like (Zlatanova, 1993) have used the rich semantic topological descriptions inherent in the IFC for describing formulas derived from mathematical theories, to identify spatial networks in a building floor plan, enhancing the isolation of network relationships in space from the detailed geometrical representations, and enabling transparent decision making regarding connectedness of elements. It eliminates the clutter evident in geometric plans and 3D models. 2.5 IFC CERTIFICATION

Fig. 17 Information representation using the IFC (Zlatanova, no date)

The IFC is a vendor neutral exchange format designed to translate data from proprietary software applications. Certification is a method for software conformance testing to ensure that the internal structures of proprietary applications can map correctly to the IFC format in import and export. The IFC Certification process is enforced by the buildingSMART â&#x20AC;&#x201C; Model Support Group (MSG).

2.5.1 MODEL VIEW DEFINITIONS The latest release of the IFC schema is the IFC4 and it represents over 700 groups of individual entities, that is, classes of information defined by common attributes (Amor, 2015). A collaborative project will probably never require all the entities defined in the IFC schema for an interoperable exchange. Thus, building SMART provided the Model View Definition (MVD) approach for effective software conformance testing. 36

MA Architectural Design

The MVD defines the subset of all referenced data in the IFC schema required to support a specific type of exchange workflow using specific industry software. The most widely implemented definition so far was the IFC 2 x 3 Coordination View 2.0(CV 2.0) released in 2007. The Coordination View was designed for design coordination between the architectural, mechanical and structural engineering tasks during the design phase(buildingSMART, 2010). Subsequent releases of Model View Definitions are the IFC4 Reference View and IFC4 Design Transfer View which were published in 2013. The IFC4 design transfer view will be used in this study and is discussed further in Chapter 3. MVDs can also be developed by other organisations outside buildingSMART using the ifcDoc tool. Efforts towards the development of the IFC5 are underway (buildingSMART, 2017a, 2017b).

2.5.2 INFORMATION DELIVERY MANUALS (IDM) The methodology for defining model views can be referred to as an Information Delivery Manual. An Information Delivery Manual describes a framework for scenarios of exchange using proprietary BIM applications, including a description of the kind of actors, information, and level of completion required in a data model for a successful interoperable exchange. The Information Delivery Manual is a set of instructions that describe the exchange process using IFC test cases. It is delivered to end-users as a kind of teaching manual. IDMs are targeted at syntactic interoperability (correct mapping between the IFC syntax and the software syntax). They are therefore limited in their capacity to represent information rich models authored from several design participants (Lee et al., 2014). Software vendors are expected to improve the internal structure of their applications after the IDM has been developed (buildingSMART, 2011). An application is classified as certified when exchange issues identified after the development of an Information Delivery Manual have been resolved (Lipman et al. 2011). DMs have been accepted as an international standard ISO 29481.

Akpezi Ikede 160244203

INFORMATION DELIVERY MANUAL

Actors and Activities

PROCESS MAP

Non-technical Information that must be exchanged

EXCHANGE REQUIREMENTS

FUNCTIONAL REQUIREMENTS

Basic functionalities of the model

CONCEPTS

Fig. 18 Diagram illustrating the types of information available in a Delivery Manual (Kinviniemi, 2006). Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean feig massa.

MA Architectural Design

2.6 CHECKING FOR ERRORS WITH THE IFC The IFC schema is designed for simplicity, to enable communication with the plethora of authoring software that exists in the AEC-FM domain. Inherently some information within the IFC will map to definitions within the software’s internal structure. In this regard, a completely seamless interoperable exchange may never be achieved, as most software vendors create their packages to encourage more complex definitions since their purposes are usually market-driven, whereas the IFC would increase in simplicity to accommodate translation with more applications.

2.6.1 IFC MODEL ERRORS Lee et al.(2016) describes metrics that could form the basis for IFC evaluation criteria and broadly classifies the three kinds of error validation for an IFC as: • Syntactic, •

Semantic and,

•

Design programming requirements validation.

Syntactic problems are usually created by incorrect binding of proprietary software formats to the IFC during import or export, typically a result of misunderstanding the IFC file requirements. A syntactic validation entails checks to the IFC EXPRESS schema. Ifc entities and their respective attributes are designed in a hierarchal structure where the root entity informs the description of its inherited entities. For example, IfcMaterial will refer its data to the IfcWall root entity. Semantic validation requires that relationships to IFC entity subsets be described for referencing between root and inheritance attributes to function. Semantic data needed for specific exchange scenarios are necessary to specify Model View Definitions. Design programming requirements validation will be the subject of investigation in this study. A design program includes client requirements, spatial definitions, building regulation codes, stakeholder-specific information such as architectural, structural or MEP (Mechanical, Electrical and Plumbing) Requirements. It also entails the validation of construction plans, circulation/emergency exit definitions, health and safety information, energy rules, and cost/quantity take-off information. Validation for design programming errors require an application that allows designers apply the constraints intended in specific rule-sets that can run automatically using simple commands (Lee et al., 2011) Applications such as Solibri Model Checker and Tekla BIMsight has been designed specifically for this purpose. 39

Akpezi Ikede 160244203

2.6.2 METHODS FOR ERROR CHECKS WITH THE IFC Certain errors occur during IFC-based file exchange that is not a direct consequence of limitations to the schema. According to Pazlar and Turk (2008), errors in an exported or imported file could occur as a result of; •

Differences in semantics of exported and imported IFC files due to incomplete mapping

•

Uncommon artefacts which may not exist in the importing software database.

Data trip tests are used by independent researchers to assess the frequency of these kinds of errors with IFC certified applications.

2.6.2.1 DATA TRIP TESTING The export of a data model from its source of creation to the IFC is regarded as a data trip. These kinds of tests have been used for software conformance testing by independent organisations in addition to buildingSMART’s Model View Definition approach. The current MVD methods give assurance for only specific test cases, proving that software marked as certified can work well with the IFC. However, it does not assure that an IFC export from certified software can also translate properly into other design tools. Fig 19 presents illustrations of the directions of exchange that have been used for previous software conformance tests. Data trip tests are used by independent organisations and researchers to point out areas for improvement both for software vendors and buildingSMART international. These tests form the major basis for the methods chosen in this study. Amor and Ma (2006) describe a round trip as a method for interoperability testing that tests preservation of information between certified applications. Round-trip tests provide a case study that eliminates the need to test a design tool against all the other tools available in the market, which could be very expensive if at all completely possible. A full round trip involves the export of a data model from an authoring software to the IFC format to another editing or non-editing user, and then back to the originating author of the data. A pure round trip describes import and export exchange within a single certified software, but typically round trips imply exchange between different software (Pazlar and Turk, 2008). These experiments entail the comparison of two IFC files, before and after import into a BIM editing software. Comparisons were made either by manual checking for changes to IFC text files or by using automated IFC analytical tools.

MA Architectural Design Transfer for further editing

AUTHORING FORMAT

IFC

EDITING USE

One-way Transfer

AUTHORING FORMAT

IFC

AUTHORING FORMAT

IFC

NONEDITING USE

IFC

EDITING USE

AUTHORING FORMAT

IFC

FM HANDOVER

AUTHORING FORMAT

IFC

EDITING USE

Full Round Trip Fig. 19 Categories of file data trips in IFC conformance testing (Author reproduction based on source, buildingSMART International, 2017f)

Akpezi Ikede 160244203

2.6.3 RESULTS FROM PREVIOUS STUDIES Interoperability tests using one or more the type of round trips illustrate in Fig 19 have been used to assess the efficiency of the IFC as a mediator for file transfer in previous research. An overview of the methods employed in previous research is described in Table 1 and 2. The table shows the authors that have conducted these experiments in the past, the design and IFC tools used for modelling analysis, the kind of models they used to perform these tests. The authors in this table have been represented by corresponding letters A - G in Table 3.

Table 1 Overview of Round Trip Tests in Past Research

AUTHOR

Kiviniemi (2006) IFC Exchange Test at the IAI Forum, Denmark

Pazlar and Turk (2008)

Jeong et al., (2009)

CONCLUSION • •

• • •

Pure round trip (ADT-IFC-ADT) provided the most accurate results. IFC is still not completely reliable. The IF interface will most likely not 'self-correct' and attempts towards improvements should not be based on bugs dicovered while-in-use only.

•

None of the geometries exported completely, some circular geometry were transformed to squares. IFC is the only candidate for effective geometry and information exchange. IDM and MVD for exchange with precast concrete should be developed.

• •

Lee et al., (2011)

Nizam and Zhang (2015)

Ryu et al. (2016)

G Muller et al., (2017)

Certification does not prove that import/export will work properly with a model. Tekla proved to be most incompatible in exchange, working only with IFC 2 x 2 version of models.

• •

Exports showed loss of details, and slight changes in objects orientation and position. Only 30% of GUID were preserved in exchange.

• •

Tekla was most incompatible with the IFC Pure architectural objects such as doors and windows were the most poorly represented.

• •

Linear data did not convert properly IFC4 was proposed as a preferable alternative to IFC 2 x 3 for free-form conversion.

•

Interoperability improved over five years by 38%, although there were some drawbacks.

MA Architectural Design Table 1 Continued Overview of Round Trip Tests in Past Research

Author Kiviniemi (2006) IFC Exchange Test A at the IAI Forum, Denmark

Pazlar and Turk (2008)

C Jeong et al., (2009)

Lee et al., (2011)

Nizam and Zhang (2015)

Ryu et al. (2016)

G Muller et al. (2017)

Design Tools

IFC tools

Models Checked

Autodesk Architectural Desktop, ArchiCAD, Bentley Architecture, Tekla Structures.

Not mentioned. ArchICAD as used to check IFC properties.

•

Building with walls, door and opening, with materials applied.

• • •

Simple Wall, Wall with opening and, Complex residential and office buildings.

•

Exchange tests using .sat and .dwg formats. Ten units of precast, and cast-in-place concrete models with complex geometry, and pre-stressed hollow core precast concrete slab panels.

Autodesk Architectural Desktop, Allplan.

Counters: TNO IFCEngineBasic, GEM IFCQuickBrowser, FZH IFCObjectCounter. Viewers: TNO IFC Engine Viewer, FZH IFCViewer, DDS IFCViewer .

Revit Building, ArchiCAD, Digital Project, Bentley Architecture, Tekla Structures, Structureworks.

Solibri Model Viewer, IFC Quick Browser, TNO IFC Engine Viewer.

Revit Building, Constructor + ArchiCAD, Microstation Triforma, AllPlan, Tekla Structures.

EVASYS (for counting IFC instances), DDS CAD Viewer, Acrobat Pro (to confirm results from the viewer), Compare P21(designed by authors to analyse metrics).

Revit Tekla Structures

NIST IFC Analyzer, Tekla Bimsight, Solibri Model Checker.

Rhino 3D, Revit, ArchiCAD.

Revit, TQS, RQT,

•

88 test cases generated with the software of 32 Ifc 2 x 3 models from buildingSMART online carrying 15 object types.

•

One room structure (50sq ft.) Two storey building (3200 sq ft.)

•

Testing IFC representations of linear, segmented and free-form parametric models using .sat and .stl formats for export into BIM tools.

•

Structural models including beams slabs and ccolumns. A three-storey buiilding with parking spaces between 2011 and 2016.

Solibri Model Checker

IFC Model Viewer

•

Akpezi Ikede 160244203 Table 2 Errors identified with IFC after exchange process

AUTHORS ERRORS IDENTIFIED

Changes to IFC file size



Geometric differences(Visual)



Geometry differences (Semantic)



Change in Object Position (Global XYZ)



Change of Object GUID







Ifc entities added



Ifc entities removed



Change to material descriptions

 = Mentioned - = Not Mentioned  = Suggested for future Research



MA Architectural Design

CHAPTER 3 METHODOLOGY The IFC has been identified as the most suitable effort towards solving interoperability challenges. However, past research studies as described in the previous chapter have identified several weak points within the IFC format, in its ability to transfer information correctly without the loss of significance and meaning. The specific objectives of this study are to identify: 1. The levels of information exchanged at the different stages of BIM collaboration. 2. The problems that exist with current data exchange and the solutions which exist currently to address them, 3. The limitations of these solutions identified in (3) above. Experimental methods for IFC model checking will be used for this study.

Pazlar and Turk (2008) describe two methods of comparing changes in IFC object properties and semantics: •

Text Comparison: This is a manual method for visually comparing two or more IFC text files. However, the diverse sequence of entities present in an IFC text file makes manual comparison tedious, especially for larger models. This makes it a less preferable method for IFC data validation. Unlike the HTML (Hypertext Markup Language) format where each line of code is sequential, the IFC format is slightly randomised, and a simple change in one line of syntax will not create a corresponding adjustment to the object output (Laakso and KInvieniemi,2012). For this project, the NIST IFC Analyzer(IFA) will be used to translate the IFC text formats into spreadsheets. However, direct text comparisons will not be made.

•

Object Comparison: This is an automated method used to compare the IFC files for both syntactic and semantic errors, using programs which allow object based visualisations of the IFC file. Recently, programs like Tekla BIMsight and Solibri Model Checker(SMC) have been created with detailed rulesets for IFC comparisons. In this study the Model Revisions Comparison ruleset in SMC’s BIM Architectural Validation template will be used. The ruleset is designed to automatically detect and changes to components and space definitions by comparing two models. The results include checks to several entities described in the IFC. For this project, the Solibri Model Checker will be used for automated object comparisons, while the data presented in the spreadsheets from the NIST IFC analyser will to validate results derived by the SMC.

Akpezi Ikede 160244203 EXCHANGE SCENARIO BETWEEN TWO ARCHITECTURAL FIRMS REVIT 2018

ARCHICAD-64

FIRM A

FIRM B

Creates building model based on expertise required for the project

Specifies: Primary Objects: Wall, window Floor etc. Geometry Objects positions Object Dimensions Object Types and Labels (Semantic descriptions) Materials Assigned Layers Levels (IfcContainedIn Element) Object Phase: New Construction

INTERNATIONAL DESIGN TEAM

Places building model in site context with appropriate landscaping expertise required for the project

IFC TRANSFER

Modifies: Primary Objects: Wall, window Floor etc. Geometric Representation Objects Positions Object Types and Labels (Semantic descriptions) Object Phase: New Construction Materials

SAME PROJECT

Fig 20 Exchange scenario between two architectural firms(Author's Own)

Specifies: Object Phase : Existing

LOCAL ARCHITECTS

MA Architectural Design 3.1 EXCHANGE SCENARIO The methodology illustrated in Fig 20 describes a method of exchange between two architectural firms working on the same project. Firm A has trained all its staff to work with Revit Architecture 2018 and Firm B uses ArchiCAD-64 for all of its projects. Firm A is responsible for designing the conceptual building model at the pre-design phase, and Firm B is expected to finish the design detailing before transfer to other project stakeholders. Firm B has been chosen because of their proximity to the construction site. The client desires foreign design concepts from the international Firm A but requires local firm B to look over the model before construction to ensure that the design suits its host environment. As Revit and ArchiCAD do not have a direct format for file transfer, firm A will transfer their part of the building Model to Firm B using the IFC format. The architect in Firm A will have to design each building object on a virtual site with level boundaries. Each space and object in the building will be assigned a label with descriptions. Furthermore, architect A will provide specific dimensions for objects and material assignments to the building objects. As some artefacts are on the current site, the phase of each element of the building model will be defined as either Existing or New Construction. Fortunately, each object in the IFC schema carries a globally unique identifier(GUID) which allows differentiation between several objects of the same type. Thus, similar objects carrying different properties should be translated properly into the software used at Firm B without changes to their GUID. Most importantly, the model should be visually accurate, and geometric representations of solids must be preserved for ArchiCAD to generate dependent views like section cuts and elevations accurately.

3.2 EXCHANGE TESTS In an ideal working condition, the information required for Firm B to interpret the model correctly should be preserved with the IFC. However past studies have shown challenges with the IFC in preserving all model details, and in some cases, loss of GUID occurs. The exchange tests in this research will be carried out to verify the ability of the IFC to represent accurately the information detailed by Firm A in an exchange using Revit and ArchiCAD. Simpler models were utilized in the tests to enable detailed analysis of the IFC file. More complex models would have a larger number of entities which cannot be interpreted within the scope of this research.

Akpezi Ikede 160244203

A list of possible metrics for forming IFC evaluation criteria has been described in detail by Lee et al. (2011). The criteria used for assessing the preservation of information using the IFC4 Design Transfer View are:

1. Import and Export Success for all objects created in the original model. 2. Visual Differences: Visual changes to the geometric definitions as an outcome of the exchange tests will be identified and documented using the Solibri Model Checker. 3. Differences in file size: The size of the IFC file after each export and import process will be compared. 4. Preservation of GUID: The GUID is a universal identification number for IFC instances and ideally, should be preserved in all cases of exchange. Only primary objects will be checked for preservation of GUID. 5. Changes in entity definition: This will include changes to the total number of entities present in the IFC file. 6. Changes in Position and Dimension: All objects are assigned dimension values to describe size, and occupy a unique position in 3D Euclidean Spaces (Global XYZ). Any changes to these values will be documented. 7. Variations in labels and descriptions: Past research has identified significant distortion of semantic information in the IFC due to incorrect of incorrect binding with the internal naming structure of most proprietary BIM software. Changes to semantic descriptive data reduces clarity in information. Changes to material, layer and phase descriptions will also be identified. 8. Geometric Representations: Characteristically, there are three ways geometry is represented in the IFC file; Solid, Boundary Representation(B-rep), or surface, with its mode of creation being either Extruded or faceted. The preservation of shape representation is important as it affects subsequent edits to a building model, could lead to incorrect results in energy analysis (as the volume and boundaries of geometry are required for energy calculations) as well as directly affecting file size.

MA Architectural Design 3.3 SOFTWARE TOOLS 3.3.1 BIM DESIGN TOOLS ArchiCAD and Autodesk Revit are two of the most widely used BIM solutions in architecture. Both Revit and ArchiCAD support the direct export of IFC files without external plugins. ArchiCAD has been marked as the most IFC compatible software, and both Revit and ArchiCAD are certified for IFC import/export. A full list of IFC certified software are listed in the Appendix. The software versions used for this project are Revit Architecture 2018 and ArchiCAD-64.

3.3.2 IFC TOOLS Solibri Model Checker(SMC) The Model Comparison ruleset under the BIM- Architectural Validation presets will be used in SMC to compare the IFC models before and after the exchange. The Model Revisions Comparison ruleset cross-checks two models for any changes in space and component object types. The errors identified include revisions to owner history, and changes to attribute values for all entities. After checking, changes organised in a hierarchical structure based on each object type and compiled in a detailed report.

Fig. 21 Solibri Comparison Report for Test Case X4 (Solibri Model Checker, 2017)

Akpezi Ikede 160244203 NIST IFC File Analyzer(IFA) The IFC Analyzer created by Lipman(2017) for the National Institute of Standards technology can assess IFC files and translate data into Microsoft Excel Spreadsheets. Information extracted is grouped information according to property sets for each entity. The IFC analyser will help to identify precise changes in the IFC text files which the Solibri Model Checker identifies as errors. IFA supports analysis of IFC2X3, IFC2X3_RC1 IFC2X3_RC2 and IFC4 definitions.

IFC 4 Design Transfer View All models were exported using the IFC4 Design Transfer View in both Revit and ArchiCAD. The IFC4 is the latest Model View Definition release from buildingSMART. The IFC4 Design Transfer View includes corrections to technical problems identified since the release of the IFC2x3. It included enhanced capabilities for the IFC specification to retain its main architectural, building service and structural elements. The new schema includes additional geometry types and parametric features. The IFC4 Design Transfer View is the successor of the IFC2x3 Coordination View. It is intended to be compatible with the IFC2x3 Coordination View for import(buildingSMART International, 2017c)

BIM TOOLS TOOLS USED

Revit Architecture 2018 Archicad- 64 Nist Ifc Analyzer Solibri Model Checker IFC TOOLS

Fig 22 Tools used for experiments(Author's Own)

MA Architectural Design 3.4 TEST CASES The test cases used for the experiments were chosen to address issues with the exchange of IFC data models with relevant architectural, structural and MEP information using IFC certified software Autodesk Revit and ArchiCAD. The architectural IFC test cases were chosen as separated building elements for simplicity in analysing the IFC text files as complex models create larger instances, which may be too difficult to study as the IFC syntax is not precisely sequential. A full description of the test cases is given in Table 2. For best practices, the IFC test models were provided by BuildingSMART and IFC Auckland. Simple models were also created in ArchiCAD-64 and Revit 2018 to test their accuracy in the export of IFC data.

Each test model used in this study consists of a group of objects as described in Table 1. Models X1-X9 consist IFC models with three of the models authored in BLIS (Building Lifecycle Interoperable Software) testing environment, two in Microstation Triforma and two with IFC DLL Engine and Allplan respectively. The remaining models were authored in Revit Building 9.1, ArchiCAD 9, Revit Architecture 2018 and ArchiCAD- 64. Four models out of these were created by the author of this project. The IFC models were first checked using the Solibri Model checker to assess the level of correctness of information before import and export commenced. The downloaded IFC models have been renamed for clarity. A total of 18 test cases will be used to check the preservation of information in different exchange directions A full description of all the test cases used for the experiments is given in Table 3 - 5.

3.5 TEST SUMMARY The purpose of the experiments made in this project is to: •

Identify errors in the exported IFC against the Imported IFC.

•

Describe the significance of errors to a non-expert user of the IFC.

The data trip tests used in the experiments can be broadly classified into 3: •

Tests using IFC files

•

Tests using Revit Models

•

Tests using ArchiCAD models

Akpezi Ikede 160244203 Table 3 -IFC Test Cases

X1(A)

Name: Hello_Wall Author: buildingSMART Type: IFC4 model Objects: Opening, Wall, Window

Name: Roof with openings Author: IFC2X_MicroStation Triforma Type: IFC2 x 3 model Objects: Roof with 4 openings

Name: Building Element Properties Author: BLIS IFC R2.0 Test Cases Type: IFCR2 model Objects: Building Components with material properties

Name: Simple Brick Wall Author: BLIS IFC R2.0 test cases Type: IFC R2 model Objects: Wall

Name: Brep beams with openings Author: IFC2X_MicroStation Triforma Type: IFC 2 x 3 model Objects: Beams with openings(3)

Name: Hello_House Author: buildingSMART Type: IFC4 model Objects: Walls, Roof, Slab

Name: Swept Solid Wall Author: IFC Engine DLL version 1.02 beta Type: IFC 2 x 3 model Objects: Opening, Wall, Window

Name: Steel Columns Author: ALLPLAN 2006 Type: IFC 2 x 3 model Objects: Steel Columns(4)

Name: IFC R2 Building Author: BLIS IFC R2.0 Test Cases Type: IFC R2 model Objects: Walls, Slab, Door, Openings, Column

MA Architectural Design Table 4 - Revit Test Cases

Name: Curtain wall Author: Revit Building 9.1 Type: IFC 2 x 3 model Objects: Opening, Wall, Window

Name: Door Inside Wall Author: Revit Building 9.1 Type: IFC 2 x 3 model Objects: Doors(8), Walls (2).

Name: Stair (L-shaped) Run Author: Revit 2018 Type: IFC 4 model Objects: Rails, Stair Material

Name: Stair (Circular Run) Author: Revit 2018 Type: IFC 4 model Objects: Rails, Stair Material

Type: IFC 4 model Objects: Brick Wall(4), Curtain Wall(1), Door, Roof, Slab

Name: Revit House mini Author: Revit 2018

Table 5 - ArchiCAD Test Cases

Name: Ifc slab with Railing Author: ArchiCAD 9.1 Type: IFC 2 x 3 model Objects: Slab, Railing

Name: Walls with Openings Author: ArchiCAD 9.1 Type: IFC 2 x 3 model Objects: Exterior Walls(4), Interior Partition, Window, Opening, Door

Name: ArchiCAD_house_mini Author: ArchiCAD-64 Type: IFC 4 model Objects: Wall(4), Window, Door, Roof, Slab, Load bearing Columns(4)

Akpezi Ikede 160244203 The arrow lines in Fig 23 represents the direction of exchange for each experiment.

ck he C

BIM TOOL

SOLIBRI MODEL CHECKER

EXPORT

IFC

C he ck

IMPORT

IFC

ck he C

NIST IFC ANALYZER

Fig. 23 Exchange work-flow for the experiments

All models will be imported and exported to the IFC4 Design Transfer View in ArchiCAD and Revit. The file state before the exchange and after will then be compared using the Solibri Model Checker(Solibri, 2016) and NIST IFC Analyzer(Lipman, 2017). A.

Tests using IFC files

For the first set of tests, the exchange directions are represented by the arrows in Fig. 24. IFC files will be exported through Revit and ArchiCAD and then compared against each other and the original file.The first round of tests involved importing the IFC test cases from the University of Auckland Open IFC library (Henderson, 2016) and buildingSMART International(2017d) example models for IFC4 named Hello_Wall and Hello_building.

ECK H C REVIT

IFC

CHECK

IFC ARCHICAD

IFC

Fig. 24 Direction of exchange for the first set of tests

MA Architectural Design

The second round of tests involved models authored in Revit and ArchiCAD. The Revit and ArchiCAD exported IFC will then be compared against the original.

Tests using Revit Models

CHECK IFC

REVIT

ARCHICAD

IFC

Fig. 25 Direction of exchange for Revit models

Tests using ArchiCAD models

CHECK

ARCHICAD

IFC

REVIT

IFC

Fig. 26 Direction of exchange for ArchiCAD models

Akpezi Ikede 160244203

An additional test which has been described as a pure round trip in the previous chapter will be performed by reimporting and exporting models authored in Revit and ArchiCAD. This test illustrates a scenario where Firm B decides to attempt using the same software the IFC was created in to get better results with the model transferred from Firm A.

CHECK

REVIT

IFC

REVIT

IFC

CHECK

ARCHICAD

Fig. 27 Pure round trip

IFC

ARCHICAD

IFC

MA Architectural Design

CHAPTER 4 RESULTS The experiments made in this project are not geared towards identifying a solution but are an attempt at identifying common trends in the possible outcome of errors expected with exchange using the selected BIM tools. The results presented are not a universal indication of errors to expect with the IFC. They have been obtained based on the selected test cases and tools used for analysis. Improper modelling practices by the model authors and default import and export settings in the BIM tools used have affected the outcome of the experiments. The results as shown in Tables 7 â&#x20AC;&#x201C; 10 have been grouped according to the most common errors identified during the exchange tests. Other errors identified with the specific model will be discussed subsequently in the chapter. IFA provided the entity count described in the bar charts which were compared against file sizes. These numbers included entity types not processed by the application.

Fig 28 Some entities were not processed (NIST IFC Analyser Report, 2017)

Overall, assigned layers and descriptive labels for object types, levels, and layers were not preserved during an exchange with both software.

Akpezi Ikede 160244203

According to the scenario described in Fig 20, the initial requirement of the architects at Firm B is access the model provided by Firm A. This means that the IFC models must import correctly before further development can take place. In these experiments, the BLIS and buildingSMART models failed to import completely in both Revit and ArchiCAD, even though exported IFC produced a constant 87 and 64 entities respectively in all cases. The NIST IFC Analyzer was able to process all the test files except for the buildingSMART IFC4 examples. Solibri Model Checker imported all the models successfully, except for Revit models R1 and R5. Table 6 shows a summary of import and export successes and failures.

MA Architectural Design

Table 6 - Import and Export Results

- Successful. Most objects are present and information translation is successful.  - Unsuccessful, more that 90% of the model is removed (either visuals or information).

IFC MODELS

REVIT

ARCHICAD

IMPORT EXPORT IMPORT

NIST IFC ANALYZER

EXPORT IMPORT

SOLIBRI MODEL CHECKER

IMPORT

X1 Hello_Wall





X2 Simple Brick Wall





X3 Swept-Solid Wall



X4 Roof with openings







X5 Brep beams with opening







X6 Steel Columns



X7 Building Element Properties





X8 Hello_House













R4 Stair (Circular Run)



R5 Revit House mini





Ifc Slab with Railing (B-rep)



A2 Walls with Openings



A3 ArchiCAD House mini



IFC R2 Building

R1 Curtain wall R2 R3

Door Inside Wall Stair (L-shaped Run)

Akpezi Ikede 160244203

X3 - Swept-Solid Wall Swept-Solid Wall File Size

Entities 226 186

163

11 IFC FILE

AFTER REVIT EXPORT

AFTER ARCHICAD EXPORT

Visually all the objects in the model were preserved by both BIM tools. However, the window object changed from an extruded swept solid to a boundary representation in both software, even though the other object representations were preserved. The layers, materials and type definitions for this model were undefined oriiginally. Export from ArchiCAD revealed that such undefined properties had been assigned default ArchiCAD descriptions. The position of the wall and window also shifted along the Y-axis in ArchiCAD. Visually, all objects appeared to be in their appropriate locations. The total number of entities increased after export from Revit and ArchiCAD.

Table 7a - Results from IFC models  - preserved o - not preserved  undefined Owner Application: IFC Engine DLL version 1.02 beta

Revit 2018

ArchiCAD-64

Primary Objects



GUID for primary Objects



Geometry(Visual)



Geometric Representation



Objects positions(Global XYZ)

Object Dimensions



Object descriptions and labels



Materials



Assigned Layers



Levels



Object Phase



MA Architectural Design

X4 - Roof with openings Roof with openings File Size

Entities 912

423

147 39.7

8 IFC FILE

AFTER REVIT IMPORT

17.2 AFTER ARCHICAD IMPORT

The exported Revit IFC failed to import in SMC. The differences between Revit and ArchiCAD definitions for entities were revealed through the IFA spreadsheets. The original IFC definition for the roof object contained IfcSlab and IfcOpening elements. After export, these entities were merged into one definition of IfcRoof in Revit and IfcSlab in ArchiCAD. Geometric representations changed from extrusion to boundary representations in both software. The descriptions for the IfcOpening elements in the roof varied after ArchiCAD export causing SMC to describe it as a removed element. Dimensions for the object’s perimeter, thickness and gross Area were not preserved in ArchiCAD. The total number of entities increased to more than double its original number, with a drastic increase in Revit exports.

Table 7b - Results from IFC models  - preserved o - not preserved  undefined

Owner Application: MicroStation Triforma Ifc 2 x _

Revit 2018

ArchiCAD-64

Primary Objects



GUID for primary Objects



Geometry(Visual)



Geometric Representation



Objects positions(Global XYZ)



Object Dimensions



Object descriptions and labels



Materials



Assigned Layers



Levels



Object Phase



Akpezi Ikede 160244203

X4 - Brep beams with opening(3) Brep beams with opening File Size

Entities 3236

3152

1274

161

133

59 IFC FILE

AFTER REVIT IMPORT

AFTER ARCHICAD IMPORT

This particular model was chosen to check if the geometric conversion from extrusion to Boundary representation(Brep) identified in previous tests also applied for elements created as Brep. The geometry of the Brep beams was preserved, but the opening elements which created the void cuts through the beams were converted from extrusion to boundary representation. The changes to the opening elements were significant enough for SMC to identify all the openings as entities added. The beams imported correctly into Revit into ArchiCAD. However, the Solibri Model Checker was unable to import the Revit IFC file. The triangle counts for all three beams reduced, and the bottom area dimensions for all three beams changed. Undefined type names were assigned default descriptions by ArchiCAD. Table 7c - Results from IFC models  - preserved o - not preserved  - undefined

Owner Application: MicroStation Triforma Ifc 2 x _

Revit 2018

ArchiCAD-64

Primary Objects



GUID for primary Objects





Geometry(Visual)



Geometric Representation





Objects positions(Global XYZ)





Object Dimensions



Object descriptions and labels



Materials



Assigned Layers



Levels



Object Phase



MA Architectural Design

X6 - Steel Columns(4) Steel Columns File Size

Entities 224

217

146

14.6

13.3

8 IFC FILE

AFTER REVIT IMPORT

AFTER ARCHICAD IMPORT

The Revit profile height and width dimensions for the columns were interchanged. The type definition in the ArchiCAD IFC changed from concrete to custom profile. The Global X and Y positions of the ArchiCAD export changed. Descriptions for object hierarchy (Site – Default Building) changed with the Revit export. The total number of entities increased consistently in Revit and ArchiCAD respectively.

Table 7d - Results from IFC models  - preserved o - not preserved  - undefined Owner Application: ALLPLAN

Revit 2018

ArchiCAD-64

Primary Objects



GUID for primary Objects



Geometry(Visual)



Geometric Representation



Objects positions(Global XYZ)



Object Dimensions



Object descriptions and labels

Materials



Assigned Layers

Levels

Object Phase

Akpezi Ikede 160244203

R1- Curtain Wall

IFC 2 X 3 Curtain Wall File Size

Entities

1990

1146 521 66 REVIT BLDG 9.1 IFC

34 AFTER REVIT EXPORT

128 AFTER ARCHICAD EXPORT

The Revit building curtain wall (R1) had significant material changes in ArchiCAD. Metal was converted to Aluminium background, and Glass, the defining element for the curtain wall, was converted to Background in ArchiCAD. A change to the bottom elevation property of the Revit IFC caused a shift in the position of the object. The Revit export converted the entire wall into a single boundary representation removing the curtain walls original 40 rectangular members and 16 glazing plates. Nevertheless, GUID for the wall element was preserved.

Table 8a - Results from Revit Models  - preserved o - not preserved  - undefined Owner Application: Revit Building 9.1

Revit 2018

ArchiCAD-64

Primary Objects





GUID for primary Objects



Geometry(Visual)



Geometric Representation



Objects positions(Global XYZ)



Object Dimensions





Object descriptions and labels



Materials



Assigned Layers



Levels





Object Phase



MA Architectural Design

R2- Door Inside Wall Revit- Door Inside Wall File Size

Entities

959 806

451

52 REVIT IFC

29 AFTER REVIT IMPORT

AFTER ARCHICAD IMPORT

The Revit model R2 (Door inside Wall Placement) was created originally in Revit building 9.1. Despite the similarity in authoring platforms, materials and object types were not preserved after export from Revit 2018. Additionally, the door operations changed from Single Swing Right to undefined in ArchiCAD. The position of door six was also altered and changed the extruded walls to boundary representations. The triangle counts for walls increased in both software. Undefined layer, material, phase and level properties were assigned Revit and ArchiCAD defaults.

Table 8b - Results from Revit Models  - preserved o - not preserved  - undefined Owner Application: Revit Building 9.1

Revit 2018

ArchiCAD-64

Primary Objects



GUID for primary Objects



Geometry(Visual)



Geometric Representation



Objects positions(Global XYZ)



Object Dimensions



Object descriptions and labels

Materials

Assigned Layers

Levels

Object Phase

Akpezi Ikede 160244203

R3 - Stair (L-shaped Run) Stair (L-shaped Run) File Size

Entities

10347

1460

592

REVIT IFC

AFTER ARCHICAD IMPORT

585

PURE ROUND TRIP

This model was authored in Revit 2018. The export failed to represent all the stair properties visually. Object properties which were visually absent after export were represented by the IFC as shown in the IFA spreadsheet. Most of the object properties were preserved in the full round trip. The stair changed from Extrusion to Brep on the second import. Material descriptions changed upon import into ArchiCAD. The Oak-Wood floor material changed to Background. The total number of entities reduced drastically upon subsequent imports in both ArchiCAD and Revit.

Table 8c - Results from Revit Models

 - preserved o - not preserved  - undefined Owner Application: Revit 2018

ArchiCAD-64

Revit 2018 (Pure Round Trip)

Primary Objects



GUID for primary Objects



Geometry(Visual)



Geometric Representation



Objects positions(Global XYZ)



Object Dimensions



Object descriptions and labels



Materials



Assigned Layers



Levels



Object Phase



MA Architectural Design

R4 - Stair (Circular Run) Stair (Circular Run) File Size

Entities

29574

2163 REVIT IFC

6506

3349

360

144 AFTER ARCHICAD IMPORT

PURE ROUND TRIP

The export of this model from Revit failed significantly in its preservation of information. Despite significant changes to the Revit circular stair in export, its material properties were preserved in a pure-round-trip with Revit. The material changed from Oak wood flooring to IFC building Material when it was imported into ArchiCAD. Furthermore, object descriptions were altered in ArchiCAD. Similar to R3, the total number of entities reduced drastically upon subsequent imports in both ArchiCAD and Revit.

Table 8d - Results from Revit Models

 - preserved o - not preserved  - undefined Owner Application: Revit 2018

Revit 2018

ArchiCAD-64

Primary Objects



GUID for primary Objects



Geometry(Visual)



Geometric Representation



Objects positions(Global XYZ)



Object Dimensions



Object descriptions and labels



Materials



Assigned Layers



Levels



Object Phase



Akpezi Ikede 160244203

R5 - Revit House mini Revit House mini File Size

Entities

804 649

339

42 REVIT IFC

AFTER ARCHICAD IMPORT

PURE ROUND TRIP

The Revit mini house was designed by the author for this project. It contains floor, four walls, curtain wall (as window element) and roof objects. Additionally, Revit insulation and dimensions were included in the original model. The insulation and dimension elements were not preserved in export. Also, the IfcRoof element was preserved but failed to appear visually in SMC and in the Revit pure round trip. The roof, however, appeared upon import into ArchiCAD. ArchiCAD

definitions

did

not

preserve the glass and roofing

Table 8e - Results from Revit Models

 - preserved o - not preserved  - undefined

materials used for the model, but the wall materials were retained. Glass material descriptions changed

Owner Application: Revit 2018

ArchiCAD-64

Revit 2018 (Pure Round Trip)

simply to Background. Also, the

Primary Objects



slab details changed in ArchiCAD.

Functions



GUID for primary Objects



Geometry(Visual)



Geometric Representation



Objects positions(Global XYZ)



Object Dimensions



Object descriptions and labels



Materials



Assigned Layers



Levels



Object Phase



ArchiCAD slab configurations differ from Revit thus reducing the overall thickness of the slab from 480mm to 470mm. Visually, the model was imported correctly into ArchiCAD, but object dimensions and positions changed for all the objects in the mini house.

MA Architectural Design

A1 - Ifc Slab with Railing (B-rep) Ifc Slab with Railing File Size

Entities 741

636

402

ARCHICAD- 9 IFC

REVIT 2018 IFC

ARCHICAD - 64 IFC

This model was authored in ArchiCAD 9.1. In Revit, its floor type changed from concrete floor to slab. The Global Z dimension for the slab changed, and the Global X and Y positions for the Rail were altered. Level descriptions changed from Floor 0 to Level 1. The ArchiCAD import did not affect the model significantly. Material definitions were updated to the current ArchiCAD descriptions.

Table 9a - Results from ArchiCAD Models

 - preserved o - not preserved  - undefined Owner Application: ArchiCAD 9.0

Revit 2018

ArchiCAD-64

Primary Objects



GUID for primary Objects



Geometry(Visual)



Geometric Representation



Objects positions(Global XYZ)



Object Dimensions



Object descriptions and labels

Materials



Assigned Layers

Levels

Object Phase



Akpezi Ikede 160244203

A2 - Walls with Openings Walls with Openings File Size

Entities 3214

2307 1945

144

101 ARCHICAD - 9 IFC

REVIT 2018 IFC

ARCHICAD-64 IFC

In Revit, the wall reference for partition the partition Walls in the model changed to External Walls. The door operations also changed. The wall volume, area, and length values were altered and the wall triangle count increased. In ArchiCAD, the operations for all the door elements changed. Also, level descriptions changed from Floor 0 to 0 Story. The total number of entities reduced after Revit Import but increases with ArchiCAD-64.

Table 9b - Results from ArchiCAD Models

 - preserved o - not preserved  - undefined Owner Application: ArchiCAD 9.0

Revit 2018

ArchiCAD-64

Primary Objects



Functions





GUID for primary Objects



Geometry(Visual)



Geometric Representation



Objects positions(Global XYZ)

Object Dimensions

Object descriptions and labels

Materials

Assigned Layers



Levels

Object Phase

MA Architectural Design

A3 - ArchiCAD House mini ArchiCAD House mini File Size

Entities 3059

1951

1918

141

94 ARCHICAD-64 IFC

AFTER REVIT IMPORT

PURE ROUND TRIP

This model was authored for this project using ArchiCAD-64. The house contains four walls with a floor and roof, with door and window elements, as well as four structural columns. The walls and floor were assigned load-bearing functions and thermal transmittance values. These properties were preserved in both Revit and ArchiCAD exports. The material of the roof changed in Revit from Wood- Hardwood Roof to Timber roof. The slab thickness also changed in Revit as the extra 20mm layer of finish created by ArchiCAD did not match Revit’s floor descriptions. Visually all objects were view accurately. The total number of entities increased significantly with Revit but slightly in the ArchiCAD round trip.

Table 9c - Results from ArchiCAD Models

 - preserved o - not preserved  - undefined Owner Application: ArchiCAD-64

Revit 2018

ArchiCAD-64

Primary Objects



Functions



GUID for primary Objects



Geometry(Visual)



Geometric Representation



Objects positions(Global XYZ)



Object Dimensions



Object descriptions and labels

Materials

Assigned Layers

Levels

Object Phase



Akpezi Ikede 160244203

4.1 ANALYSIS OF RESULTS Models with duplicated components (such as R2 -Door Inside Wall and X6 - Steel columns) presented similar changes across all the objects. However, the position of some objects changed while others remained the same. The results shown in Tables 6 - 9 are discussed under the following subheadings.

Attribute – Unit of information within an entity. Entity - Class of information defined by common attributes. Instance – Occurrence of an entity. Object – A distinctive piece of a building model made up of several entities. Type - A basic Information construct derived from a selection of entities.

Fig 29 Definition of IFC terms used in the discussion

4.1.1 IMPORT AND EXPORT SUCCESS Out of the 18 test cases used for this project, all the models authored by BLIS failed to import. However, a constant file size of 6kb and entity count of 87 and 64 (for Revit and ArchiCAD exports respectively) were documented despite import failures. This indicates that some entities will be preserved in any exported IFC model regardless of export success or failure. The Microstation Triforma Models (X4 - Roof with openings and X5 - Beam with openings) imported successfully into Revit. The exported Revit files, however, failed to import into SMC, even though the IFA spreadsheet showed that the IFC entities were preserved. Visually, all the geometries were translated properly in Revit and ArchiCAD, except for the staircases created in Revit which failed at the first point of export. Both defined and undefined labels and object type descriptions(such as material, or type name) changed in most cases, taking up the closest description as interpreted by the importing application. For example, the type description would assume the identity of the assigned material label. Changes to descriptive labels of object types and layers were an expected outcome, as it is a direct consequence of the different kinds of naming classifications in BIM tools as defined by the software vendors.

MA Architectural Design Before

After

Before

After

Fig 30 Revit Stairs before and After Export

4.1.2 DIMENSIONS AND POSITION The architect defines the dimensions of objects such as length, area, thickness and volume and positions the object in three-dimensional Euclidean space(Global XYZ) when creating spatial definitions. This information is vital for any adjustments to a design model and is useful for quantity take-off and energy analysis of building volumes. The results revealed that object positions were not preserved in all cases. Clashes and disruptions between two objects as a result of a shift in an objectâ&#x20AC;&#x2122;s position are problematic in real-life exchange situations. For example, the placement of an engineerâ&#x20AC;&#x2122;s object is often relative to or dependent on the placement of architectural objects.

4.1.3 MATERIALS Overall, material descriptions were preserved in more cases with Revit exports than with ArchiCAD. The predominant loss of material information in ArchiCAD in contrast to Revit could be a result of the internal naming structure of ArchiCAD. Revit is known to have more generic naming definitions for objects. For example, while there are clear distinctions for Revit ceiling, and floor, ArchiCAD has all descriptions for such horizontal members as slab. Materials are important specifications for architectural communication, as well as for structural calculations and energy analysis. Changes to material information may be can create inaccurate data in automated calculations with the BIM model. Nevertheless, such errors are often easily overlooked in components with less obvious material detailing such as staircases.

Akpezi Ikede 160244203 4.1.4 LABELS AND DESCRIPTIONS In building projects, the architectâ&#x20AC;&#x2122;s model is typically the starting point for other industry professionals to input additional information. Thus, the architect takes time to give specific semantic labels and descriptions to building types and objects. The results indicated that some descriptive properties which are used for identification by stakeholders were not preserved. In reality, this would create confusions between professionals working on the same model as semantic tagging of objects is the primary way to identify object properties. Additionally, building levels, and layer descriptions were not preserved, which disrupts the communication height constraints set by the author of the model.

4.1.5 FUNCTION AND PHASE CHANGE Descriptions can applied to objects in models to specify performance and functional properties such as fire rating, acoustic properties or thermal rating. Also, the status or phase at which a particular object operates communicates the level of action that can be taken with such objects to all the project actors . The three phase definitions in most cases are; existing, new construction, or demolition. An existing object would imply that modifications are limited whereas a new construction can be subject to diverse levels of modifications if necessary. Although the project phase for most of the models used in the experiments were undefined, their descriptions changed predominantly after ArchiCAD exports. Changes to object functions were also discovered as the Swing Operation of the Door in R2-Door Inside Wall and A2 walls with openings changed. Wall references for internal partition walls in A2 were also reordered to be external walls. Since the visual information was preserved, these errors could be easily overlooked in manual methods of model inspection. However, these kinds of information are crucial for automated quantity take-off.

4.1.6 VISUAL TRANSLATION OF OBJECTS Past researchers (Jeong et al.,2009 and Muller et al., 2017) revealed significant setbacks in the ability of the IFC to preserve curved geometry. The Revit circular stair was chosen as a test case to examine this finding. The IFC4 Design transfer view did not translate any of the railing and stair components. The curved stringer however, was preserved geometrically. Previous results showed curved lines translated to straight lines, by losing some endpoints. Such results were not observed in this study. Furthermore, the IfcRail entity in R3 and R4 Revit staircases were not visually represented in the models viewed in SMC. However, the IFA spreadsheet revealed that their entity definitions were preserved. 74

MA Architectural Design 4.1.7 GEOMETRIC REPRESENTATION The tests revealed two major types of geometric representations; Extrusion and Boundary Representation. These represent the profiles which describe how the object geometry will behave in BIM applications. In ArchiCAD, all exports were successful, but geometric representations were not preserved in many cases as objects were converted from extrusions to boundary representations(Brep). Essentially, the object is converted from a single solid to a closed loop of lines. Changes to geometric representation are often ignored by designers using BIM for visual communication only. However, such modifications affect the ways objects behave when further edits are to be made. The implication of changes in object representations from extrusion to Brep is that software commands, automated to work easily with solid(extruded) objects are likely to malfunction. For example, in attaching dimension anchors or generating automatic section views. Pazlar and Turk (2008) identified that objects created as boundary representations had sharp increases in entity counts as they were transferred in exchange. The results indicate that increased entity counts lead to an increase in file size. Asides from over-represented entities limiting the usability of information in the model, large files will require bigger storage spaces which could limit effectiveness in managing the models. 4.1.8 PRESERVATION OF GLOBALLY UNIQUE IDENTIFIER (GUID) The GUID of IFC entities act as an identifier across all design platforms. An architect for example, who needs to transfer a model to a quantity surveyor for automated quantity take-off and costing would assign properties to objects with a distinctive GUIDs, allowing for differentiations between similar objects types. GUIDs can also allow architects to track changes between original and edited components. Preservation of GUID is considered the most important requirement for a successful exchange as it preserves the unique identity of all model objects and entities. In all the experiments, GUID was preserved by both Revit and ArchiCAD. The BLIS test cases which failed to import correctly in the BIM tools possessed indefinite GUIDS when analysed with SMC.

Akpezi Ikede 160244203 Fig 31 Total Number of entities Ifc Models

Steel columns

Brep beams with opening

Roof with Openings

Swept Solid Wall

Fig 31 shows the entity counts 0 IFC MODEL

1000 2000 3000 4000 5000 6000 7000 8000 9000 AFTER REVIT EXPORT

AFTER ARCHICAD EXPORT

for all successfully imported and

exported

models.

general, the total number of entities increased after export

Revit Models

from BIM software. The total number of entities

Revit_house_mini

were derived using the IFC Analyser. The figures counted

Stair -Circular Run

by the Analyser include entities

Stair_L-shaped Run

which the software could not process.

Door Inside Wall Curtain wall Revit 9.1 0

5000 10000 15000 20000 25000 30000 35000 40000 45000

AFTER REVIT EXPORT

AFTER ARCHICAD EXPORT

REVIT IFC

ArchiCAD Models

ArchiCAD House_mini

Walls with Openings

Ifc slab with Railing

0 ARCHICAD IFC

1000

2000

3000

AFTER REVIT EXPORT

4000

5000

6000

7000

AFTER ARCHICAD EXPORT

8000

MA Architectural Design

4.2 LESSONS LEARNT Earlier experiments with round trips in previous research revealed the IFCâ&#x20AC;&#x2122;s inability to preserve GUID for all cases (Pazlar and Turk,2008). The tests perfomed in this study showed that such problems might have been resolved, as all GUIDs were preserved in all cases of exchange. The export of older ArchiCAD models from ArchiCAD 9 into the more recent ArchiCAD-64 simulates one of the challenges facing BIM users with access to information stored over a longer period of time. In some scenarios, older models created by designers become outdated and inaccesible as software vendors continue to update their product to meet commercial demands. However, the IFC allows for preservation of such information to work with any version of the software. This is one highlight of the usefulness of IFCs for intra-operability communication within homogenous software (Kensek, 2014).

OLDER BIM TOOL

Revit Building 9.1 ArchiCAD 9.0

IFC

NEWER VERSIONS

Revit 2018 ArchiCAD -64

Fig 32 Possibilities enabled by IFC (Author's Own) The reasons behind some import failures in SMC remains unclear. It could be a result of changes to the IFC syntax which the software could not detect, but could be identified with the IFA within the text files. Some errors detected in Solibri Model Checker turned out to be less significant than the severity of results indicated. For example, in test case X5(Beams with openings), the IfcOpening element changed to IfcObject after export and was counted as an added object by SMC. Also, minor modifications to material descriptions, for example, a change from 'concrete 300mm' to 'Concrete 300mm' which do not significantly alter the meaning of the property were flagged by SMC. While this is, in fact, an adjustment to the original property description, the core material information was preserved. Therefore, the severity of errors identified using SMC requires further interpretation from the user.

Akpezi Ikede 160244203

Fig 33 Solibri results are grouped according to severity from Low to Critical(Solibri, 2017)

The building SMART examples may have failed to import in the BIM tools used for this project because they were written with the C/C++ programming language. The buildingSMART online instructions mentioned that they could be opened in Visual Studio environments. Errors in translation with models X1 â&#x20AC;&#x201C; X9 may have occurred because the were created with IFC 2 x 3 definitions. According to (buildingSMART International, 2017e), there is no guarantee that models created according to IFC 2 x 3 will export directly to IFC4. This is because the IFC4 contains modified and enriched entities different from IFC 2 x 3. Obsolete entities from the IFC 2 x 3 definitions have also been eliminated in IFC4. The increase in IFC entity definitions after export has been identified as a possible limitation to the implementation of the standard. Such increases may be caused by the generation of some redundant entities in the IFC model. Data redundancy overcomplicates the model with irrelevant information, which becomes more cumbersome for both users and software to interprete. During this research, independent tests to check the possibility of eliminating data redundancy were done using the Solibri IFC Optimizer(SIO). The graph in Fig 34 illustrates the level of optimisation offered by SIO. An algorithm for reducing redundancies in IFC files has also been presented by Sun et al. (2015). The export and import of the test cases were done using the default settings of each BIM application. It is possible that changes to the export and import setup preferences for each application would reduce the occurrence of errors.

MA Architectural Design 800 700 600 500

Total No. of Entities

400 Total No. of Entities after Optimization

300 200 100 0

10 11 12

Fig 34 Solibri IFC Optimizer Results (Author's Own)

In both BIM tools, undefined properties were assigned default identities based on the internal data structure of the importing application. The scenario illustrated in Fig 20 suggests that such changes to descriptions created by Firm A will be problematic for Firm B. This is one reason why users may abandon the IFC altogether, upon consideration of the time it would take to cross check all data against the designerâ&#x20AC;&#x2122;s original intent. However, if both designers are aware that some changes are likely to occur, certain descriptions could be left undefined and transmitted in a separate document agreed on by both parties. Although the server approach is still used by most firms to facilitate file transfer, interoperability challenges cannot be resolved with this approach as files are stored in native formats which cannot be accessed by nonauthoring applications.

Akpezi Ikede 160244203

CHAPTER 6 CONCLUSION The push for BIM implementation in architectural practice is geared towards simplifying data sharing between professionals working with different software. The variety of software used in the AEC-FM industry presents a challenge of software interoperability with the formats building data models are stored in. The Industry Foundation Classes were created to tackle these challenges but research has revealed that exchanges with the IFC standard are burdened with issues of model degradation as files are moved from one software to the next. In the study, a set of questions were posed to address these issues as a setback to effective design communication. These questions were; •

What kind of mutations happens to models during IFC exchange?

•

How significant is the lost information?

•

What lessons can be learned for improving design communication with the IFC?

Information exchange within design collaboration was studied in this project using a simple scenario of two architectural firms working concurrently on the same project in different locations. The scenario was then simulated in a series of experiments using simple architectural models and BIM tools. A total of 18 test models were imported and exported from Revit and ArchiCAD, and the resulting IFC models were analysed. The results obtained showed that precise translation of information with the IFC even with certified software is still problematic. The results from the experiments indicate that IFC is unable to preserve information completely even with certified applications. It is not within the limitations of this research to identify whether the errors documented occurred from the exporting application or with the IFC itself. Checks for this would imply analyses of proprietary formats which are usually constrained by privacy policies. There is an urgent need to address the problems with tool interoperability in BIM collaboration. In the meantime, some changes to modelling practices may help to manage the existing challenges.

MA Architectural Design

6.1 RECOMMENDATIONS FOR FUTURE RESEARCH Despite the setbacks inherent in the accuracy of data transfer with the IFC, it is still a viable solution to sustainable information sharing. In this project, much older versions of models were able to translate into newer versions through the IFC. Even in cases of exchange with homogenous software, constant updates to software versions make projects inaccessible to firms after an extended period of time. The ability of the IFC to preserve information irrespective of time definitions is a good solution to this challenge.

Some changes to IFC model attributes were outside the scope of this research and thus were not documented. This will form the basis for a much larger research project. Also, the test cases used in this project were purely geometric models created with BIM tools. Further research investigations could be tailored towards exploring interoperability between BIM and parametric design tools. The increase in recognition for the application of parametric design principles to architectural design makes this an interesting topic for investigation.

The inclusion of automated validation in BIM training may favour the implementation of the IFCs by users who prefer to avoid the challenges it presents currently. Despite the use of software to automate the design process, model validation and checks are still practised manually in most offices around the world. While improvements to the IFC are discussed, further research could investigate the implementation of automated checking systems in the BIM workflow before the files are sent for editing. This way, designers can check for errors in exported IFC by themselves and stop the errors from ever moving forward, either by changing their modelling approach or creating a manifesto to accompany the model as it is sent to the user, clearly explaining the original intent for any model inconsistencies. Modelling training should also include lessons to improve the quality of embedded data in the IFC layers for each BIM tool.

The architects model is fundamental for other project participants to add their information to the building model. Investigations on interoperability between architectural BIM tools and other professional BIM tools, such as structural engineering or MEP can be examined in further research studies.

Akpezi Ikede 160244203

IFC TRANSFER

ARCHITECT Places building model in site context with appropriate landscaping expertise required for the project

â&#x20AC;¢

OTHER CONSULTANTS

Electrical - Revit MEP Structural -Revit Structures, Tekla Energy Analyst - EnviMet, Revit

Fig 35 IFC transfer between Architects and other consultants

MA Architectural Design

References Achten, H. and Beetz, J. (2009) ‘What Happened to Collaborative Design?’, 27th eCAADe Conference Proceedings, pp. 357–366. Amor, R. (2008) ‘A better BIM: Ideas from other industries’, CIB W78 2008 International Conference on Information Technology in Construction, Santiago, Chile, (July 2008). (Accessed: 22 June 2017). Amor, R. (2015) ‘Analysis of the Evolving IFC Schema’, Proc. of the 32nd CIB W78 Conference 2015, 27th29th October 2015, Eindhoven, The Netherlands, (March), pp. 39–48. Amor, R., Jiang, Y., & Chen, X. (2007). BIM in 2007–are we there yet. … of CIB W78 Conference on Bringing …. Retrieved from http://www.cs.auckland.ac.nz/~trebor/papers/AMOR07B.pdf Amor, R. W. and Ma, H. (2006) ‘Preservation of Meaning in Mapped IFCs’, Building, pp. 1–4. Becerik-Gerber, B. and Kensek, K. (2010) ‘Building information modeling in architecture, engineering, and construction: Emerging research directions and trends’, Journal of Professional Issues in Engineering Education and Practice, 136(3), pp. 139–147. doi: 10.1061/(ASCE)EI.1943-5541.0000023. Berlo, L. A. H. M., Beetz, J., Bos, P., Hendriks, H., & Tongeren, R. C. J. (2012) ‘Collaborative engineering with IFC : new insights and technology’, eWork and eBusiness in Architecture, Engineering and Construction, 9th ECPPM Conference Proceedings, (December), pp. 811–818. buildingSMART (2010) Coordination View Version 2.0 Summary, MVD Releases. Available at: http://www. buildingsmart-tech.org/specifications/ifc-view-definition/coordination-view-v2.0 (Accessed: 4 August 2017). buildingSMART (2011) Information Delivery Manuals — buildingSMART International User Group. Available at: http://iug.buildingsmart.org/idms/ (Accessed: 4 August 2017). buildingSMART International (2015) Introduction. Available at: http://www.buildingsmart-tech.org/ifc/IFC4x1/ old_html/introduction.htm (Accessed: 5 August 2017). buildingSMART (2016) Technical Vision | buildingSMART | buildingSMART. Available at: http://buildingsmart. org/standards/technical-vision/ (Accessed: 1 August 2017). buildingSMART (2016b) Home — Welcome to buildingSMART-Tech.org. Available at: http://www. buildingsmart-tech.org/ (Accessed: 10 July 2017). buildingSMART (2017a) Model View Definition Summary — Welcome to buildingSMART-Tech.org. Available at: http://www.buildingsmart-tech.org/specifications/ifc-view-definition (Accessed: 4 August 2017).

Akpezi Ikede 160244203 buildingSMART (2017b) Summary of IFC Releases — Welcome to buildingSMART-Tech.org. Available at: http://www.buildingsmart-tech.org/specifications/ifc-releases/summary/?searchterm=ifc (Accessed: 4 August 2017). buildingSMART International (2017c) IFC4 Design Transfer View — Welcome to buildingSMART-Tech.org. Available

at:

http://www.buildingsmart-tech.org/specifications/ifc-view-definition/ifc4-design-transfer-view

(Accessed: 31 August 2017). buildingSMART International (2017d) Examples — Welcome to buildingSMART-Tech.org. Available at: http:// www.buildingsmart-tech.org/implementation/ifc4-implementation/helpful-examples (Accessed: 28 August 2017). buildingSMART International. (2017e). IFC4 vs. IFC2x3 — Welcome to buildingSMART-Tech.org. Retrieved August 30, 2017, from http://www.buildingsmart-tech.org/implementation/ifc4-implementation/ifc4-vs.ifc2x3-1 buildingSMART International (2017f) What is a roundtrip? Can we do round-tripping with Ifc? Available at: http://buildingsmart.org/faq/roundtrip-can-round-tripping-ifc/ (Accessed: 28 July 2017). Ciribini, A. L. C., Mastrolembo Ventura, S. and Paneroni, M. (2016) ‘Implementation of an interoperable process to optimise design and construction phases of a residential building: A BIM Pilot Project’, Automation in Construction, 71, pp. 62–73. doi: 10.1016/j.autcon.2016.03.005. Ding, L., Zhou, Y. and Akinci, B. (2014) ‘Building Information Modeling (BIM) application framework: The process of expanding from 3D to computable nD’, Automation in Construction. Elsevier, 46, pp. 82–93. doi: 10.1016/j.autcon.2014.04.009. Isikdag, U., Zlatanova, S. and Underwood, J. (2013) ‘A BIM-Oriented Model for supporting indoor navigation requirements’, Computers, Environment and Urban Systems, 41, pp. 112–123. doi: 10.1016/j. compenvurbsys.2013.05.001. Henderson, S. (2016) Open IFC Model Repository. Available at: http://openifcmodel.cs.auckland.ac.nz/ (Accessed: 19 August 2017). Jeong, Y. S., Eastman, C. M., Sacks, R., & Kaner, I. (2009) ‘Benchmark tests for BIM data exchanges of precast concrete’, Automation in Construction. Elsevier B.V., 18(4), pp. 469–484. doi: 10.1016/j.autcon.2008.11.001. Kensek, K. M. (2014) Building information modeling, Building information modelling. London : Routledge, Taylor & Francis Group, 2014. Khemlani, L. (2004) ‘The IFC Building Model : A Look Under the Hood’, The IFC Building Model: ARCBytes Feature, pp. 1–12.

MA Architectural Design Kiviniemi, A. (2006) ‘Ten Years of IFC Development - Why are we not yet there ? International Alliance for Interoperability’, IAI International Technical Management, (January 2006), p. 43. Kostof, S. (1992) The city assembled : the elements of urban form through history. Edited by G. Castillo and R. Tobias. London: London : Thames & Hudson, 1992. Laakso, M. and Kiviniemi, A. (2012) ‘THE IFC STANDARD - A REVIEW OF HISTORY , DEVELOPMENT , AND STANDARDIZATION’. Royal Institute of Technology, 17(May), pp. 134–161. (Accessed: 23 June 2017). Ladenhauf, D., Battisti, K., Berndt, R., Eggeling, E., Fellner, D. W., Gratzl-Michlmair, M., & Ullrich, T. (2016) ‘Computational geometry in the context of building information modeling’, Energy and Buildings. Elsevier B.V., 115, pp. 78–84. doi: 10.1016/j.enbuild.2015.02.056. Lee, G., Won, J., Ham, S., & Shin, Y. (2011) ‘Metrics for Quantifying the Similarities and Differences between IFC Files’, Journal of Computing in Civil Engineering, 25(2), pp. 172–181. doi: 10.1061/(ASCE)CP.19435487.0000077. Lee, J., Jeong, Y., Oh, M., & Hong, S. W. (2014) ‘A filter-mediated communication model for design collaboration in building construction’, TheScientificWorldJournal. Hindawi Publishing Corporation, 2014, p. 808613. doi: 10.1155/2014/808613. Lee, Y. C., Eastman, C. M. and Lee, J. K. (2016) ‘Validations for ensuring the interoperability of data exchange of a building information model’, Automation in Construction, 63, pp. 1–11. doi: https://doi.org/10.1016/j. autcon.2015.11.006. Lipman, R., Palmer, M. and Palacios, S. (2011) ‘Assessment of conformance and interoperability testing methods used for construction industry product models’, Automation in Construction. Elsevier B.V., 20(4), pp. 418–428. doi: 10.1016/j.autcon.2010.11.011. Lipman, R. (2017) ‘IFC File Analyzer Software’. doi: 10.18434/M3F30P. Mhmad Bayyari (2015) List of BIM Software &amp; Providers | Reviews | The BIM Hub. Available at: https:// thebimhub.com/2015/08/17/list-of-bim-software-providers/#.WPG_7NKGNPY (Accessed: 2 August 2017). Muller, M. F., Garbers, A., Esmanioto, F., Huber, N., Loures, E. R., & Canciglieri, O. (2017) ‘Data interoperability assessment though IFC for BIM in structural design – a five-year gap analysis’, Journal of Civil Engineering and Management, 23(7), pp. 943–954. doi: 10.3846/13923730.2017.1341850. National Institute of Building Sciences (NIBS) (2014) ‘Frequently Asked Questions About the National BIM Standard-United States’, (National Institute of Building Sciences). Available at: https://www. nationalbimstandard.org/faqs (Accessed: 31 July 2017). 85

Akpezi Ikede 160244203

Nizam, R. S. and Zhang, C. (2015) ‘Current state of information exchange between the two most popular BIM software: Revit and Tekla’, in. CRC Press/Balkema, pp. 175–181. Norman, D. A. (Donald A. (1993) Things that make us smart : defending human attributes in the age of the machine. Reading, Mass.: Reading, Mass. : Addison-Wesley, 1993. Paul, N. and Borrmann, A. (2009) ‘Using geometrical and topological modeling approaches in building information modeling’, ITcon Journal of Information Technology in Construction, 14(October), pp. 705–723. Pazlar, T. and Turk, Ž. (2008) ‘Interoperability in practice: Geometric data exchange using the IFC standard’, Electronic Journal of Information Technology in Construction, 13(June), pp. 362–380. Race, S. (2012) BIM demystified: an architect’s guide to building information modelling/management (BIM). RIBA Publishing. Ryu, J., Lee, J. and Choi, J. (2016) ‘Development of process for interoperability improvement of BIM data for free-form buildings design using the IFC standard’. Science and Engineering Research Support Society, 10(2), pp. 127–138. doi: 10.14257/ijseia.2016.10.2.11. Sinclair, D. (ed.) (2012) BIM Overlay to the RIBA Outline Plan of Work. London: Royal Institute of British Architects. doi: http://www.ribabookshops.com/uploads/b1e09aa7-c021-e684-a548-b3091db16d03.pdf. Solibri (2016) Solibri | Solibri Model Checker, Solibri. Available at: https://www.solibri.com/products/solibrimodel-checker/ (Accessed: 4 August 2017). Sun, J., Liu, Y.-S., Gao, G., & Han, X.-G. (2015) ‘IFCCompressor: A content-based compression algorithm for optimizing Industry Foundation Classes files’. Elsevier, 50(C), pp. 1–15. doi: 10.1016/j.autcon.2014.10.015. Watson, A. (2011) ‘Digital buildings - Challenges and opportunities’, Advanced Engineering Informatics, 25(4), pp. 573–581. doi: 10.1016/j.aei.2011.07.003. Zlatanova, S. (1993) ‘Topological Relationships and their application’. Zlatanova, S. (n.d.) ' FaciliDat: 3D Indoor model and a database schema for facility management'.[online] Available at: https://3d.bk.tudelft.nl/education/msctopics/(Accessed: 5 July 2017)

MA Architectural Design

Appendix Participants of the official buildingSMART IFC2x3 Coordination View V2.0 certification process Software Developer

Software Application

Exchange Requirement

Export/Import

Status

4Projects Ltd.

4Projects

- (*)

Import

in progress

ACCA Software S.p.A

Edificius

Architecture

Import & Export

Export: certified Import: in progress

Aconex BIM Cloud

Aconex

- (*)

Import

in progress

Asite Solutions Ltd

Adoddle cBIM

- (*)

Import

in progress

Autodesk

Advanced Steel

Structural

Export

in progress

Autodesk

AutoCAD Architecture

Architecture

Import & Export

Export: certified Import: in progress

Autodesk

AutoCAD MEP BuildingServices Export

in progress

Autodesk

Navisworks Manage

- (*)

Import

in progress

Autodesk

Revit Architecture

Architecture

Import & Export

Export: certified Import: certified

Autodesk

Revit MEP

Building Service

Import & Export

Export: certified Import: certified

Autodesk

Revit Structure Structural

Import & Export

Export: certified Import: certified

Autodesk

Revit LT

Architecture

Import & Export

Export certified Import: certified

Bentley Systems

AECOsim Building Designer

Architecture, BuildingService, Structural

Import & Export

Export: certified Import: certified

Bricsys

BricsCAD

Architecture

Import & Export

in progress

CadLine Ltd

ARCHLine.XP Architecture

Import & Export

Export: certified Import: certified

Cadwork SA

lexocad

- (*)

Import

in progress

- (*)

Import

in progress

DICAD Systeme GmbH STRAKON Data Design System

DDS-CAD MEP

BuildingService

Export

Export: certified

Design Data

SDS/2

Structural

Import & Export

Export: certified Import: in progress

Akpezi Ikede 160244203

Dlubal Software GmbH

RFEM/RSTAB

- (*)

Import

Import: certified

ETU Software GmbH

HottCAD 4

- (*)

Import

in progress

FirstInVision

CasCADos / P3cad Architecture

Import & Export

in progress

Glodon Software

Glodon Takeoff for Architecture and Structure

Architecture, Structural

Import & Export

Import: certified

Graphisoft

ArchiCAD

Architecture

Import & Export

Export: certified Import: certified

Kymdata Oy

CADS Planner

Building Service Export

NEMETSCHEK Allplan

Allplan

Architecture

Import & Export

Export: certified Import: certified

NEMETSCHEK BIM+ BIM+

- (*)

Import

in progress

NEMETSCHEK Vectorworks, Inc.

Architecture

Import & Export

Export: certified Import: certified

NEMETSCHEK Scia Scia Engineer

Structural

Import & Export

Export: certified Import: certified

Progman

MagiCad

Building Service Export

Export: certified

RIB

iTWO

- (*)

Import

Import: certified

Seokyoung Systems

NaviTouch

- (*)

Import

Import: certified

Solibri

Solibri Model Checker

- (*)

Import

Import: certified

Solideo Systems

ArchiBIM Server

- (*)

Import

Import: certified

Tekla

Tekla Structures

Structural

Import & Export

Export: certified Import: certified

think project!

think project! - (*) Collaboration cloud

Import

in progress

Trimble Germany

Plancal nova

Building Service

Import & Export

Export: certified Import: in progress

VIZELIA

Facility on line

- (*)

Import

in progress

Vectorworks

Export: certified

MA Architectural Design

Akpezi Ikede 160244203