Industry Foundation Classes

A short introduction

2011

1 Table of Contents
2  3  Introduction ..................................................................................................................................... 3  Summaries ....................................................................................................................................... 4  3.1  3.2  4  5  Français .................................................................................................................................... 4  English...................................................................................................................................... 4 

Context of the study ........................................................................................................................ 5  Presentation of the IFC model  ........................................................................................................ 5  . 5.1  5.2  5.3  Introduction ............................................................................................................................. 5  The BuildingSmart organization .............................................................................................. 5  Benefits of interoperability in AEC/FM industry ..................................................................... 6  Cost .................................................................................................................................. 6  More complex buildings .................................................................................................. 6 

5.3.1  5.3.2  6 

What is the Industry Foundation Classes model? ........................................................................... 7  6.1  6.2  6.3  Geometric Data Model ............................................................................................................ 7  Building Data Model ................................................................................................................ 7  Definition ................................................................................................................................. 8  Model architecture .......................................................................................................... 8  The EXPRESS schema ..................................................................................................... 12  The STEP‐File syntax ...................................................................................................... 13 

6.3.1  6.3.2  6.3.3  6.4  6.5  7 

IFC Certification Process ........................................................................................................ 14  Other products ...................................................................................................................... 16 

International Framework for Dictionaries ..................................................................................... 17  7.1  7.2  7.3  7.4  What is the IFD? .................................................................................................................... 17  Why use IFD? ......................................................................................................................... 17  Principle of the IFD library ..................................................................................................... 17  Current development ............................................................................................................ 18 

. Information Delivery Manuals  ...................................................................................................... 19  8.1  8.2  Principle of the IDM  .............................................................................................................. 19  . IDM Process Mapping............................................................................................................ 19 

Theoretical Studies ........................................................................................................................ 20  9.1  9.2  Read the IFC file ..................................................................................................................... 21  The beam example ................................................................................................................ 21  Experiences  ............................................................................................................................... 25  . 1 

10 

 

10.1  11  11.1  12  12.1  12.2  13       

Export with Revit ................................................................................................................... 25  Practical Project ......................................................................................................................... 25  Configurateur IFC................................................................................................................... 25  Other works ............................................................................................................................... 28  Trades coordination on numerical models ........................................................................... 28  Automatic steel frame modeling ........................................................................................... 28  Bibliography  .............................................................................................................................. 30  .

 

2   

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   

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   

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…  7   

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. 

8   

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 

  9   

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. 

10   

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 

 

  11 

 

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 

   

12   

 
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;  13   

  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.  14   

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 Developer Archimen Autodesk Autodesk Autodesk Bentley Systems Data Design System Design Data Gehry Technologies Graphisoft NEMETSCHEK Allplan NEMETSCHEK North America NEMETSCHEK SCIA Plancal Progman Solibri Tekla VIZELIA
 

Software Application Active3D AutoCAD Architecture AutoCAD MEP Revit Architecture Bentley Architecture DDS-CAD MEP SDS/2 Digital Project ArchiCAD Allplan Vectorworks Scia Engineer nova MagiCad Solibri Model Checker Tekla Structures Facility on line

Exchange Requirement - (*) Architecture BuildingServices Architecture Architecture BuildingService Structural Architecture Architecture Architecture Architecture Structural BuildingService BuildingService - (*) Structural - (*)

Export/Import Import Import & Export Export Import & Export Import & Export Export Import & Export Import & Export Import & Export Import & Export Import & Export Import & Export Import & Export Export Import Import & Export 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.   

15   

 

 
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 

 

16   

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.  17   

  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.   

18   

 
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:  19   

  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
20   

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. 
#39=IFCBEAM('000000003m54skdly000tg',#89,'Beam.1','0.4572x0.6096',$,#42,#10,$);  #89=IFCOWNERHISTORY(#88,#84,.READWRITE.,.ADDED.,1303296957,$,$,1303296957);  #42=IFCLOCALPLACEMENT(#41,#69);  #10=IFCPRODUCTDEFINITIONSHAPE($,$,(#11)); 

  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
21   

  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. 

22   

 
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.      

23   

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.  24   

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. 

25   

 
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.   

26   

 
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.     

27   

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.  28   

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.         

29   

 

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 

30