Industry Foundation Classes

A short introduction

2011 1 Table of Contents 2 Introduction ...... 3 3 Summaries ...... 4 3.1 Français ...... 4 3.2 English...... 4 4 Context of the study ...... 5 5 Presentation of the IFC model ...... 5 5.1 Introduction ...... 5 5.2 The BuildingSmart organization ...... 5 5.3 Benefits of interoperability in AEC/FM industry ...... 6 5.3.1 Cost ...... 6 5.3.2 More complex buildings ...... 6 6 What is the Industry Foundation Classes model? ...... 7 6.1 Geometric Data Model ...... 7 6.2 Building Data Model ...... 7 6.3 Definition ...... 8 6.3.1 Model architecture ...... 8 6.3.2 The EXPRESS schema ...... 12 6.3.3 The STEP‐File syntax ...... 13 6.4 IFC Certification Process ...... 14 6.5 Other products ...... 16 7 International Framework for Dictionaries ...... 17 7.1 What is the IFD? ...... 17 7.2 Why use IFD? ...... 17 7.3 Principle of the IFD library ...... 17 7.4 Current development ...... 18 8 Information Delivery Manuals ...... 19 8.1 Principle of the IDM ...... 19 8.2 IDM Process Mapping...... 19 9 Theoretical Studies ...... 20 9.1 Read the IFC file ...... 21 9.2 The beam example ...... 21 10 Experiences ...... 25

10.1 Export with Revit ...... 25 11 Practical Project ...... 25 11.1 Configurateur IFC...... 25 12 Other works ...... 28 12.1 Trades coordination on numerical models ...... 28 12.2 Automatic steel frame modeling ...... 28 13 Bibliography ...... 30

2 Introduction

My professional training takes place in the OSI department (Organisation des Système d’Information), integrated within the Information System Management of Oger. This department aims to manage all BIM‐related operations, for internal production as well as contracts for third party companies.

The BIM (Building Information Modeling) is still a new sector in the building engineering, so our missions generally included a part of research and development in order to mastering new tools provided by the information technology.

As a standard of exchange for building information models, the IFC takes part of this development processes, and Oger International needs to understand this new trend and see what possibilities its implies. It’s why I have to analyze the IFC, the market of IFC‐related software, the possibilities for practical applications and give the firm a better understanding of this model and how it can be used.

3 Summaries

3.1 Français

En tant que nouveau standard d’échange de modèles informatiques, les IFC (Industry Foundation Classes) prennent une place grandissante au sein des nouvelles technologies de conception informatique et de modélisation du bâtiment.

Ce format ouvert permet en effet l’interopérabilité entre différent logiciels de conception, de dessin, de calcul, de gestion de bâtiment, et donc d’améliorer les transferts entre les différent intervenants durant la vie du bâtiment.

Afin de maitriser ce format, il est necessaire de comprendre son fonctionnement, ainsi que ses produit associé, les IFD (International Framework for Dictionary) et les IDM (Information Delivrery Manual).

Mots Clé : IFC, Industry Foundation Classes, modélisation informatique du bâtiment, MIB, conception 3D, CAO, IFD, International Framework for Dictionary, IDM, Information Delivrery Manual.

3.2 English

As a new standard for exchanging information model, IFC (Industry Foundation Classes) have a growing importance in the new technology of computer‐aided conception and modeling of building.

This open standard allows the interoperability between various software solutions of conception, design, calculus, and management of buildings, and so improves transfers between different actors during the whole life of the building.

In order to mastering this format, it’s necessary to understand its architecture, and its related products, IFD (International Framework for Dictionary) and IDM (Information Delivrery Manual).

Key words: IFC, Industry Foundation Classes, building information modeling, BIM, 3D conception, CAD, IFD, International Framework for Dictionary, IDM, Information Delivrery Manual.

4 Context of the study

Building design and construction involve many trades which have to coordinate their work during the whole construction process. Synthesis between all building trades is now compulsory for every project.

Traditionally, coordination between design offices happens through two (or three) dimensional plans. Each designer uses these plans as a basis for their own studies them report the result on their own plans. This process implies that each trade have to redraw their plans for every revision of the building design, which lead to a loss of time, money and often errors or misunderstandings during the report.

Information technology speeds up the plans production, but design offices generally still have to redraw a part or the whole plan to be able to work with it.

The very concept of the Building Information Modeling (BIM) is to create a workflow on which all involved trades can work using the same model and without have to recreate it for the purpose of their own studies.

Successful experiences have been lead during which all trades worked on the same model drawn and processed by the same BIM application. But this solution quickly showed limited in its capacities, mostly due to limitations inherent in the software solution itself.

With the increasing use of digital model in building construction, interoperability between the various software solutions became more and more important. With the fact than only one software solution or company cannot provide for all the needs require by the AEC/BM industry (Architecture Engineering and Construction/ Building Management), different applications release by different firms have to be compatible with each other in order to avoid time consuming, expensive and inaccurate manual data capture.

5 Presentation of the IFC model

5.1 Introduction

In order to create a machine readable language for the building industry, BuildingSmart (formerly International Alliance for Interoperability) has developed a construction‐specific data model named Industry Foundation Classes.

5.2 The BuildingSmart organization

BuildingSmart is an international organization, created in 1995 as the International Alliance for Interoperability (IAI) to improve interoperability between software solutions in the AEC/BM industry. Supported by most of the important BIM software developers BuildingSmart now brings together

5 more than 500 members from 24 countries, professionals in construction sector, architects, engineers and software developers.

This organization developed three Standards to share structured building information:

 the IFC (Industry Foundation Classes) data model for exchange machine readable building information between software solutions  the IDM (Information Delivery Manuals) define processes for the exchange of information during the construction and the management phases of a project.  the IFD (International Framework for Dictionaries) defines a structure for a product database which can be linked to an open BIM model.

These standards are defined in order to allow each actor of the construction processes to share the correct data in right time, whatever their business applications or processes are.

Members are regrouped in 13 chapters depending on language or geographical area. For example, MediaConstruct is the French speaking chapter of BuildingSmart.

5.3 Benefits of interoperability in AEC/FM industry

5.3.1 Cost

In 2007, a study lead by McGraw Hill Construction, Smartmarket Report, stated that problems of interoperability between software solutions during Design and Construction phases directly cost about 3,1 % of the construction cost.

In 2009, the Club des Usagers Médiaconstruct (French Chapter of BuildingSmart) and the FFB (Fédération Française du Bâtiment) evaluated the cost of non‐interoperability support by French real estate and construction industry.

During the construction phase, direct problems of interoperability cost about 35 € for each m² of SHON (Surface Hors d'Oeuvre Nette) for new constructions. The exploitation of current buildings without interoperability cost about 2,3 €/m² per years.

These estimations only take into account the direct cost, mostly due to capture again data in new software solutions and errors generated during this recapture. But with a fully integrated BIM solution, it’s possible to optimize the design and construction processes from the beginning, and avoid most design or planning errors, which bare most of cost overrun in the AEC industry.

5.3.2 More complex buildings

3D model and free flow of information between all trades involved in a project allow realization far more complex. Architectural shapes like double‐curved surfaces or complex structures became

6 possible thanks to full collaboration between all trades and competences, each actor bringing their knowledge in the model without data loss or misunderstanding.

Furthermore, by virtually building the whole project before starting the actual construction, planning or supply difficulties can be anticipated and negotiated, leading to projects done more quickly and more important, following the planning all along the project life.

6 What is the Industry Foundation Classes model?

All computer programs need an underlining data model in order to understand and organize the data it handles. BIM software is no exception to the rule.

Two kinds of data models are used to representing building information.

6.1 Geometric Data Model

Traditional 2D CAD (Computer Aided Design) and 3D modeling software solutions use purely geometric data models. In these models, information is represented as a set of lines, squares, circles for 2D design and as basics shapes (spheres, cubes, extrusions…) for 3D modeling.

In these data models, all information is geometric and defined explicitly. For example, a line is defined with two points, each of them defined by their coordinate in the model space. Similarly, a sphere is defined by a point and a radius.

But all these geometric entities aren’t linked together to create a consistent model and remain only geometric shapes. The main advantage of such a general‐purpose geometric model, its versatility, is also its main drawback, because domain‐specific entities or properties cannot be added to the model. There is no “intelligence" behind the basic geometrical shape.

With this kind of model, a wall is simply represented as a parallelepiped. The application does not interpret it as a wall and so domain‐specific task such as a wall schedule, for example, cannot be preformed.

Limits to this kind of model lead to the creation of data organization, specific to the AEC/BM industry.

6.2 Building Data Model

Like any other domain, AEC industry has to create its own object‐based data models that are specific to the construction and building management processes. These data models are built around building entities such as walls, doors… and their relationships to one another. Each element is entitled a whole set of properties, including geometry, material, cost, planning…

These models also handle non‐physical entities such as rooms, or building levels, which cannot be represented in a geometry‐oriented model, but are part of the very description of every building. For example, a room is a fully defined entity, including its relation to walls and ceilings that bound it.

Figure 1 ‐ Differences between Geometric and Building Data Model

The development of a building‐specific data model is hardly new. Grafisoft’s ArchiCAD or Autodesk’s Revit have been using such a model since the beginning of their development. But all their internal data model are proprietary and cannot communicate with each other without specific translation scripts.

In order to achieved interoperability among all software used in the AEC industry, a similar building data model has been developed since 1995 by BuildingSmart. This model, named Industry Foundation Classes (IFC) is a non‐proprietary model and is intended to be used by all applications that are used to design, construct and manage buildings.

6.3 Definition

6.3.1 Model architecture

IFC is a modeling data model, inspired by the STEP model (Standard for Exchange of Product) and using the same language, EXPRESS.

The IFC model describes machine‐understandable building entities. Building component such as wall, door, slab are available but also more abstract concepts such as schedules, costs, spaces, activities … These entities can have a number of properties such as identity, material, cost, etc.

The IFC model does not provide a definition for any object or concept used in the AEC/FM industry, but provides general concept that can be detailed by including sets of properties. This concept allows a much more compact and better structured model. Currently, the latest release of the IFC, the IFC 2.4’s version has 759 entities, i.e. objects and concepts.

The architecture operates on a ‘gravity principle’, which means that an entity at a given level can only be related to entities located on the same level or at a lower level.

This architecture provides a model with all the qualities required:

‐ Modular structure ‐ Framework for sharing information ‐ Easy maintenance and development

Figure 2 – Overall model architecture

They are four conceptual layers in the model which are, from the lowest to the highest:

‐ Resource layer: The lowest level in the IFC’s architecture. Resources are representing basics properties or general purpose concepts that can be used by an object in an upper level for its definition, such as geometry, material, measurement… For instance, all the information concerning basic concepts of costs is collected together within the cost schema, the IfcCostResource. Any classes within the upper layers that need to use the “cost” concept will refer to this resource. ‐ Core layer: It contains the most abstract entities of the IFC model. It’s divided in two levels of generalization. The Kernel schema defines core concepts which are used in all higher‐levels entities in the model, such as actor, group, process, product, relationship, and so on. The three Extension schema define abstract elements that rely to the AFC industry. For instance, the Product Extension provides concepts for general building element such as building, space, site, building element… ‐ Interoperability layer: It provides objects and relationships commonly used and shared by various trades during the life’s cycle of the building. For instance, Shared Building Elements schema defines entities such as wall, beam, door, etc. ‐ Domain layer: The highest level of the IFC model contains entities definitions for concepts specific to each trade. For example, the HVAC Domain defines concepts for boilers, chillers, coils, etc.

6.3.1.1 Property sets: Some properties, such as the cross section of a beam, are universal, and can be hard‐coded into the model as attribute.

But for the main part of properties (=IFCPROPERTYSINGLEVALUE), which can be seen differently by different actors, such as national building codes, they are defined in a separate property set (=IFCPROPERTYSET) that can be attached (with =IFCRELDEFINESBYPROPERTIES) to the element and behave just like attributes.

6.3.1.2 Proxies Proxies are defined to create entities which weren’t been included in the IFC model. These can have a geometry, attributes and property sets just like any entities in the original model

6.3.1.3 Example

Here is an example of some common elements of the IFC schema, with their properties (in brackets), the layers where it belongs and their place in the IFC inherence tree.

IfcRoot (GlobalID, OwnerHistory, Name, Description)

IfcPropertyDefinition

ifcPropertySetDefinition

IfcPropertySet (HasPropertires)

IfcPropertySetDefinition

IfcRelationship

IfcRelDefines

IfcRelDefinesByProperties (RelatedObjects, RelatingPropertyDefinition)

IfcRelAssign

IfcRelAssociates

IfcRelConnects

IfcRelDecomposes

IfcObjectDefinition

IfcObject (ObjectType)

IfcProduct (ObjectPlacement, Representation)

IfcElement (Tag)

IfcBuildingElement

IfcWall (PredifinedType)

IfcWallStandartCase

IfcSpacialElement (LongName)

IfcSpatialStructureElement (CompositionType)

IfcSpace (HasCoverings, BoundeBy)

IfcBuilding (ElevationOfRefHeight, ElevationOfTerrain, BuildingAdress)

IfcBuildingStorey (Elevation)

IfcProcess

IfcControl

IfcRessources

IfcActor

IfcGroup

IfcProject

IfcContext

IfcProject Kernel Elements Products Extension Elements Shared Building Elements

Figure 3 ‐ Architecture example

6.3.2 The EXPRESS schema

Industry Foundation Classes are based on the EXPRESS language. It is a data modeling language defined both textually and graphically. This language can explain any data model that formally defines data objects and their relationships.

Datatypes

There are six types of data in the EXPRESS language:

‐ Entity ‐ Enumeration: Simple strings defined in a list ‐ Defined: Further specializes other datatypes definition ‐ Select: Define a choice or an alternative between different options. ‐ Simple (String, Binary, Logical, Boolean, Number, Integer, Real) ‐ Aggregation (SET, LIST, BAG, ARRAY)

The entity datatype can have attributes relating entities together in a specific role. There are three different kinds of attributes, explicit (direct value), derived (from an expression) and inverse(name and constrain an explicit value) attributes.

An entity can be defined as a subtype of one or several other entities, called supertype. A supertype can have any number of subtypes.

As an example, here is the EXPRESS schema of a family. The "father" and "mother" links are Optional Attribute Symbols, linking the entity "Person" with entities "Male" and "Female".

SCHEMA Family;

ENTITY Person ABSTRACT SUPERTYPE OF (ONEOF (Male, Female)); name: STRING; mother: OPTIONAL Female; father: OPTIONAL Male; END_ENTITY;

ENTITY Female SUBTYPE OF (Person); END_ENTITY;

ENTITY Male SUBTYPE of (Person); END_ENTITY;

END_SCHEMA; Figure 4 ‐ Family Schema in EXPRESS

Figure 5 ‐ EXPRESS‐G datatype

6.3.3 The STEP‐File syntax

The IFC‐file is a text format defined by the ISO 10303‐21 standard, know as STEP‐File, the most widely used data exchange of STEP. The syntax of the IFC‐file follow the same format.

The IFC structure is easily readable, with one entity per line, and code links to reach other lines. An usual IFC text file looks like this:

ISO‐10303‐21; HEADER; FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1'); FILE_NAME('','2011‐03‐29T16:21:42',(''),(''),'Autodesk Revit Structure 2011 ‐ 1.0','20100615_2115(x64)',''); FILE_SCHEMA(('IFC2X3')); ENDSEC; DATA; #1=IFCORGANIZATION($,'Autodesk Revit Structure 2011',$,$,$); #2=IFCAPPLICATION(#1,'2011','Autodesk Revit Structure 2011','Revit'); #3=IFCCARTESIANPOINT((0.,0.,0.)); #4=IFCCARTESIANPOINT((0.,0.)); #5=IFCDIRECTION((1.,0.,0.)); #6=IFCDIRECTION((‐1.,0.,0.)); #7=IFCDIRECTION((0.,1.,0.)); .... #34=IFCPROJECT('23c3cizZTENPj2HHp24VPd',#33,'',$,$,'','',(#27,#28),#23); ENDSEC; END‐ISO‐10303‐21;

The file is divided in two parts:

The HEADER contains general information about the file and its creation.

The DATA section contains the IFC lines :

#34=IFCPROJECT('23c3cizZTENPj2HHp24VPd',#33,'',$,$,'','',(#27,#28),#23);

‐ Instance name: #34. It's the GUID (Globally Unique IDentifier) of the entity ‐ Instance description: IFCPROJECT ‐ Instance attributes between ()

Attribute values can be defined in the entity or as a referenced instance.

As an example, here, '23c3cizZTENPj2HHp24VPd' is the GUID of the project, #33 is the Owner of the model, '' is the name of the project, $ and $ are two unset attributes, respectively the description and the object type, '' is the Long Name, '' is the phase of the project, (#27,#28) is a set of references for the Representation Context and, #23 is a reference to Units used in this project.

6.4 IFC Certification Process

In order to increase reliability of models generated by applications claiming support of IFC, Building Smart has set up a process of certification for these applications. This process has been recently updated so as to “improve the quality of software interfaces and to strengthen the rigidness of certification.” Major CAD software developers have signed‐in for this new “IFC Certification 2.0”.

6.4.1.1 General workflow for certification All the certification process is made through the Global Testing Documentation Server (GTDS). Candidates use this server to download the test files and report their results.

After the registration, software developers must create export files on their own software application. These files must be designed solely from scratch, based only on 2D DXF drawings and references coordinates. All this material is provided by the BuildingSmart Certification Program. These files covers different fields of the IFC implementation:

‐ General test (for example for persistence of the GUID’s, support of character sets, etc…) ‐ Entity specific test (a beam or a wall for example) ‐ Small complex test cases (a small house…)

Once these files have been exported, the software developer must checks accurate points in order to certify the good result of his export.

The Import Certification relies more or less on the same principle, with IFC files created for this purpose by BuildingSmart and checked after their import in the software application.

The export and import test files are manually checked, both by a self check by the software developer and by a counter check by the certification tester.

Currently, all these software developers have register to certificate their implementation of the IFC in these software applications, with first official certifications expected by autumn of 2011.

Software Exchange Software Developer Export/Import Application Requirement Archimen Active3D - (*) Import AutoCAD Autodesk Architecture Import & Export Architecture Autodesk AutoCAD MEP BuildingServices Export Autodesk Revit Architecture Architecture Import & Export Bentley Systems Bentley Architecture Architecture Import & Export Data Design System DDS-CAD MEP BuildingService Export Design Data SDS/2 Structural Import & Export Gehry Technologies Digital Project Architecture Import & Export Graphisoft ArchiCAD Architecture Import & Export NEMETSCHEK Allplan Allplan Architecture Import & Export NEMETSCHEK North Vectorworks Architecture Import & Export America NEMETSCHEK SCIA Scia Engineer Structural Import & Export Plancal nova BuildingService Import & Export Progman MagiCad BuildingService Export Solibri Model Solibri - (*) Import Checker Tekla Tekla Structures Structural Import & Export VIZELIA Facility on line - (*) Import

6.4.1.2 Some tests To understand these tests, I have myself sent some files to the GTDS where an automatic checking tool from Karlsruhe Institute of Technology checks the IFC code to find out some basical problems, but does not check the files with the new Coordination View Version 2.0.

With files created with Digital Project, the checking does not find many problems, but the software cannot read IFC files made in Revit.

Figure 6 ‐ Overview of the GTDS web interface

6.5 Other products

A real free flow of information needs not only a standardized exchange format, but also a definition of what and how we exchange information. Three factors are needed:

1. An exchange format used to define information (Digital Storage) 2. A specification of which information to exchange and when to exchange it (Process) 3. A user‐friendly reference in order to know what information is actually exchange (Terminology)

To create this complete Open BIM standardized solution, BuildingSmart also builds and maintains two related specifications, the Information Delivery Manual IDM and the International Framework for Dictionaries IFD.

Figure 7 ‐ Interoperability through Standards

7 International Framework for Dictionaries

7.1 What is the IFD?

Standardized understanding of what the exchanged information actually is

7.2 Why use IFD?

While the IFC format defines an exchange standard for building information between different software solutions, it does not define all possible concepts used in the AEC/FM industry. Building description in the IFC format relies mainly on geometries, with associated properties such as the type of the object, the material, the name of the object… Mains concepts are defined as IFC component, such as IfcWall or IfcSpace, but most of properties are define as plain text string.

As an example, the occupation of an IfcSpace (a room) is defined by the architect as “Kitchen” in his design application (Revit for example). In order to calculate the structure, an engineer needs to know the right design load for each room, and thus the occupation of each room. The receiving application, which helps the engineer to calculate the structure (Robot for example), will understood the meaning of “Kitchen” with difficulty, even if “Kitchen” is correctly spelled. With most complicated concept, or between different languages, it becomes virtually impossible without using the IFD.

7.3 Principle of the IFD library

The aim of the IFD library is to define these concepts and terms and give them a unique identification number, or GUID (Globally Unique IDentification). Strings like names are understood by the user while the underlying GUID is understood by the computer.

The IFD library works with the IFC format and provides the IFC model with concepts used in the AEC/FM industry to create a complete representation of a building.

The IFD library is currently in development, and aims at replacing the definition currently stored in the IFC model.

Contents within the IFD library are organized in two types:

‐ Concepts (labeled as Terms) define things that can distinguish from other. Concepts are labeled by Names and linked through a naming relationship. One concept can have many labels (synonyms or different languages) and one Name can refer to various concepts. ‐ Characteristics (labeled as Properties) are the concepts which cannot be related to others. Their meaning is provided through a description. There are only a few types of Characteristics: Behavior, Environmental influence, Function, Measure, Property and Unit.

Concepts are related to other with relationships, depending on the context. For example, what we see as a door can be different concepts, depending on how we are using it.

Figure 8 ‐ Different concepts for a door

A computer used thee different concepts through their GUID, which provided a unique identification for them.

These concepts allow an architect to define a door as a way between two spaces (first concept), while a structural engineer will see it as an opening in a structural wall (second concept) and a carpenter will see it as an assembly of a door leaf and a door frame (two more concepts). All these concepts are linked together and can be understood by specialized software application in each trade.

7.4 Current development

Currently only Dutch and Norwegians have created their own IFD library. Dutch are leading a project to harmonized these two projects and create a shared global and multilingual dictionary.

The core of these system are object oriented data based, stored on centralized servers, based on the EXPRESS standard. This standard allows using the EPM Technology’s EDM Server, a proprietary solution for storage of this standardized format. Several browser are being developed to explored concepts, definitions and properties stored on these servers, such as the Browsalizer developed by buildingSMART Norway and Standards Norway.

Figure 9 ‐ Overview of the Browsalizer interface

8 Information Delivery Manuals

8.1 Principle of the IDM

Building Information Modeling allow each trades to describe and display the information required for the design, construction and operation of constructed facilities into a single operating environment. By bringing together the different threads of information, it allow to reduce and even eliminating exchange of paper‐based data. To release the benefits of this workflow, information from everyone must be available when it’s needed. For this to happen, each actor involved in the design or construction process must work in a common integrated workflow. Here is the goal of the Information Delivery Manual (IDM).

The IDM provide a common reference for processes and data exchange within a BIM workflow. It aims to describe precisely building construction processes for both BIM users and BIM solution provider.

8.2 IDM Process Mapping The IDM standard is a process map, used to understand tasks, activities, actors and information involved in the AEC/FM industry. It uses the Business Process Modeling Notation or BPMN to draw this process map.

As an example, here's an overview of the Top Level Structural Engineering Process Map:

1. Activities are shown within a "container" knows as a "swimming pool" indentified by the role of the concerned actor. 2. Activities are divided by department knows as "swimlanes" indentified by a role. 3. Activity is represented by a rounded rectangle, usually named by an action and an object. An identifier is given in a yellow box. 4. Activities in the same swimming pool are linked by arrow 5. A dashed line arrow is used to pass information to another swimming pool. 6. The End Evens occur at the end of the process 7. The Start Even occur at the beginning of the process 8. Gateways are used to control the splitting and joining of sequence flows, they represent decision. 9. An "Exchange requirement" define the data involve in the communication between two different swimming pool.

9 Theoretical Studies

9.1 Read the IFC file

The STEP language is made to be easily understood both by a computer and an human reader. Relations between elements are written clearly in a .txt file. But when dealing with a whole building model, the IFC file can contained thousand of lines. As an example, the structural model of one of the building of the Canopé Des Halles project had about one million lines.

To understand the IFC structure of such model and the exporting process both in Digital Project and Revit, I first created an application in order to sort and extract specific element of the IFC text file.

This application, developed in VB.NET create in an Excel spreadsheet the inheritance tree for any IFC entities specified in the message box shown above.

This application read the parent line and find all the reference for children entities ( # and a number). Then it find the IFC file the child line themselves, and insert them below the parent line in the next row.

This operation is applied line by line on each row until every child are founded :

#39=IFCBEAM('000000003m54skdly000tg',#89,'Beam.1','0.4572x0.6096',$,#42,#10,$); #89=IFCOWNERHISTORY(#88,#84,.READWRITE.,.ADDED.,1303296957,$,$,1303296957); #88=IFCPERSONANDORGANIZATION(#87,#85,$); #84=IFCAPPLICATION(#86,'V1R4SP7','Digital Project','Digital Project'); #42=IFCLOCALPLACEMENT(#41,#69); #41=IFCLOCALPLACEMENT($,#69); #69=IFCAXIS2PLACEMENT3D(#62,#75,#76); #10=IFCPRODUCTDEFINITIONSHAPE($,$,(#11)); #11=IFCSHAPEREPRESENTATION(#71,'Body','SweptSolid',(#17));

This application allow me to quickly generate, analyze and compare inheritance trees for specific IFC entities.

9.2 The beam example

To understand how any object is defined in the IFC model, I have look in the exported IFC files of beams of different shape from different software.

A beam, like any other AEC/FM object is design as an object (IfcBeam) with an Id (IfcGloballyUniqueId), a Name (IfcLabel), a position (IfcObjectPlacement), a geometrical representation (IfcProductRepresentation) and optionally a type (IfcBeamTypeEnum).

There are two categories of geometrical representation in the IFC model.

Simple geometrical shape can be represented with traditional 3d modeling operations, such as extrusion, rotation, swept along an axis... These geometrical representations retains the elements' parameters value, such as thickness, height, reference axis... These parameters are easily modifiable, so the shape can be edited. This is the form usually supported by static analisys program which support basic shape However, complex shape cannot be realized with these methods.

The Boundary representation (BREP) can represent any shape by assembling triangles to create the boundary surface of the object. If this representation can reproduce precisely the shape of any object, the element's parameters are lost and the imported object is not editable anymore.

Figure 10 ‐ Slanted wal

Here, this wall can be seen as an architectural wall, where its shape must follow the other wall, but also as geometrical representation of a structural element which don't need to be slanted to be structurally representative.

Figure 11 ‐ Slab with slanted edge

We have here the same choice between an extruded geometry easily editable and a more precise surface‐based representation.

Figure 12 ‐ Chained beams

In case of a chain of elements, an extruded representation will juste show each beam, with their axis and their lenght. We will not be able to modify a surface‐based representation, but the shape of the interseerction will be correctly represented.

The definition method of a beam is similar in Revit and Digital Project. The IFCBEAM entity own an IFCPRODUCTDEFINITIONSHAPE which generate the geometrical representation of the beam. For any strait beam, this geometry is created by extruding a profile along an axis. The profile is generally define as an assembly of lines and curves which create a closed profile.

Furthermore, Revit adds in this IFCPRODUCTDEFINITIONSHAPE the representation of the axis of the beam.

Different ways to define the geometrical shape of a beam :

IFCBEAM

GlobalId IfcGloballyUniqueId As GUID

OwnerHistory ‐ IfcOwnerHistory

Name IfcLabel As String

Description IfcText As String

ObjectType IfcLabel As String

ObjectPlacement ‐ IfcObjectPlacement

IfcLocalPlacement

Representation ‐ IfcProductRepresentation

IfcProductDefinitionShape

IfcRepresentationItem

IfcBooleanResult

IfcBasedSurfaceModel

IfcShellBasedSurfaceModel

IfcSolidModel

IfcManifoldSolidBrep

IfcSweptAreaSolid

IfcExtrudedAreaSolid

IfcRevolvedAreaSolid

IfcSweptDiskSolid

Tag IfcIdentifier As String

PredifinedType IfcBeamTypeEnum As Enumeration

The model include various possibility to create various representation shapes from meshes, extrusion, revolution, sweep, boolean operation on solid or any other creation method allow in 3D modeling software.

The basic element of all geometrical shapes is the IfcCurve, with can be a straight line, a circle, an ellipse, a parametric curve, a polyline, a Bézier curve or a curve generate from a surface.

The only limitation seems to be complex surfaces, with 2 dimensional curvature and generate from 2 or more 3D splines. Nevertheless, these kink of complex shapes can be approximate with mesh‐ based surfaces.

10 Experiences

10.1 Export with Revit

One of my first experiences with the IFC export was to create an IFC file with Revit then import it into a new Revit project. Here are the first results of the import of a wall:

‐ A wall still have his base constrain to a level (Level 1 for instance) but have lost his upper constrain. It now defined as a wall with a specific height. ‐ Wall alone stay as a wall system family as we import the IFC file in Revit ‐ Wall with a host stays as a wall system family as we import the IFC file in Revit. The host stays as a Loadable Family, but the Family Name is lost, only the Type Name is kept

11 Practical Project

11.1 Configurateur IFC

One of the most advanced IFC‐based project is the "Configurateur IFC", developed since May 2009 by the group Saint‐Gobain, specialized in building materials, in partnership with the CSTB (Centre Scientifique et Technique du Bâtiment), a public research center for innovations in building construction.

After having discovering it during a presentation of the CSTB products, I have meet M. Ortas, responsible for the development of the Configurateur IFC at Saint Gobain, who have help me understand it.

The Configurateur IFC is a "Smart" construction products catalog made by Saint Gobain. It generate automatically partitioning walls and linings with metal frame, glass wool insulation and plaster board on an IFC model

The "Configurateur IFC" had two functions ordinary realized by a human technician. Firstly, it find the best insulation system depending on local regulations, expected thermal efficiency and general configuration of the building. Then it instantiate this system with the correct support frame layout, depending on room shape and openings position.

Figure 13 ‐ The automatically instantiated insulation system

This Configurateur IFC links together various database around an IFC model shown on the open source IFC model viewer developed by the CSTB, EveBIM.

After analyzing dimensions of the room and associated thermal parameters, it search the correct system in the Saint Gobain's products database. These products are described following the DTH format (Dictionnaire Technique Harmonisé). This format, developed with the AFNOR (Association Française de Normalisation) by Saint Gobain, aim to standardized the description of building construction product in order to make their characteristics understood by any software solution using these rules.

Various systems are checked to be conform with the regulation define in specific format in a second database.

Then it write the IFC file to merge into the model the new partitioning walls with the correct properties and quantities.

Figure 14 ‐ Configurateur IFC principle

The development of the Configurateur IFC have been made in relation with BuildingSmart, and had allowed to find some lack in the IFC definition. Some new IFC classes, such as IfcExternalCoverings, are currently in study after improvement remarks from the Configurateur development team.

12 Other works

During my internship, I have been part of other projects along with my studies about the IFC model. Here’s a short presentation of these works.

12.1 Trades coordination on numerical models

One of the current projects of Oger International is on a tower at Monaco. The contract involves the coordination of the studies of different trades on the project using a numerical model of the building.

The main subject is the detection of clashes between different objects design by each contractors. To do so, drawings from each trade are integrated into a common Revit model. Then a clash detection is realized within Naviswork, a software solution from Autodesck which detect interferences between geometrical representation of objects which make the model. It produces a list of reports detailing clashes with their parameters (GUID, position, elements involved …).

But this reports aren’t enough accurate to be useful for the synthesis work. We have to locate on the common Revit model the position of each clash and extract a detailed plan of its area.

In order to automate this process, I have realized an add on for Revit which extract the information linked with each clash and use it to create detailed plans of the area involved, with its location on the model.

Naviswork have the ability to export clash reports on a XML format. By studying these files, I was able to create a VB.NET application that read it and extract relevant information about each clash.

One I have this information, I use the position’s coordinates to highlight the clash in the Revit model, and create automatically a drawing of the area.

Other information, likes IDs of elements involve in the clash allow me to display the correct view of the model, where all elements are visible and well framed on the plan.

With an Excel application developed by my colleague, it became possible to place this planes on an Excel datasheet, with all relevant information about the intersection, and then create automatically a fully report for each clash.

12.2 Automatic steel frame modeling

Our scope of work on the Midfield Terminal Complex implies to create a model of the steel structure from the roof. This structure follows the complex shape of the roof and is made of about 250 parts each with one main beam, about ten purlins, and 30 “Top Hat” purlins. The numbers of elements made it too long to draw it piece by piece.

To realize it, I have firstly drawn the wireframe of the main structure, supporting each of the 250 main parts. The point of this was to create references where I can instantiate the same element 250 times, by using one of the functions of Digital Project. This element will be made of a main beam, a various number of purlins and “Top Hat” purlin, insulation and the roof cladding.

But if Digital Project can easily adapt dimensions of elements depending of the references, it cannot actual create new ones. I have to develop a VBA application which creates the correct number of purlins and “Top Hat” purlins, depending on the span of the main beam. This application measures the length of the main span and calculates the correct numbers of purlins to make up, given some rules for placing them.

I finally create a common element which can adapt to its position, and using another BVA script, place it on each location, following the wireframe structure.

13 Bibliography

Thomas Liebich, Jeffrey Wix, (October 27, 2000) IFC 2x Technical Guide

Lachimi Khemlani, (March 30, 2004) The IFC Building Model: A look under the hood. AECbytes http://www.aecbytes.com/feature/2004/IFCmodel.html

http://en.wikipedia.org/wiki/Industry_Foundation_Classes ‐ Wikipedia’s page, March 1st, 2011

http://en.wikipedia.org/wiki/ISO_10303‐21 ‐ Wikipedia ISO 10303‐21’s page, December 29th, 2010

BuildingSmart’s home page ‐ http://buildingsmart.com/

Official technical specification on IFC ‐ http://www.iai‐tech.org/

IFC 2x3 Reference Guide for ArchiCAD 15 ‐ Grafisoft – 2011

IFD Library White Paper ‐ http://www.ifd‐library.org

IDM Learning Guide ‐ http://www.iai.no/idm/index.html, February 18, 2011