IFC Export rules part 2

IFC Export rules. Part 2: What parameters to export? Dos and Don’ts

You wish to make your weekly IFC export, but every time, you are not sure what parameters to include in it, to satisfy the needs of project participants? Don’t worry, we get you covered! This entry will answer this question and you will understand what to include in the IFC export!

In the last blog post, I focused on why IFC export is important. There has been a great discussion on LinkedIn, partially about why do we even use IFC export instead of just continuing designing directly in the IFC model? Why is there still no reliable solution on the market?
Though I also agree that such a thing would be awesome, we have to stick to what we have at the current moment. And that is a workflow that requires frequent delivery of IFC file version 2×3. Although IFC 4 is getting more and more recognition, software producers are lagging behind with certification. This is quite unfortunate since IFC 4 solves many issues known in 2×3.

Back to this entry though! ! I’ve tried to build a comprehensive list, yet keep it on a general level – different companies and even different projects might have their specific export requirements. If you have a good rule to add somewhere below – just hit me on LinkedIn, email or comment below the article!

Table of Contents

General rules for IFC export and parameters

You always have to keep in mind some set of rules when setting up your model and exporting IFC parameters. Those are often described in BEP or other documents describing modelling principles for each project. Some Dos and Don’ts’ that are important to remember are listed below.

Dos

  • Give a model a correct name according to the project/standard requirements (read about requirements in ISO19650 here)
  • Remember about common project parameters such as IfcProject.Name, IfcSite.Name, IfcBuilding.Name, IfcBuildingStorey
  • Define correct coordination point, level, rotation and True North
  • Export your discipline zero-point object
  • Define correct rooms and levels boundaries
  • Objects should exist only on one level (with some exceptions, like longer columns supporting facade elements)
  • Assign correct levels to all objects (heights)
  • Use correct object types and assign correct classes to objects, even if they are modelled using a different object in the modelling software (a common example of stairs being modelled as slabs, and then exported as so. Architect should manually classify them as stairs)
  • Objects have to have defined correct material layers with their thickness
  • Use logical and consequent instance naming (especially doors, lighting fixtures)
  • Remove placeholders for other disciplines (e.g. walls, sinks, switchboards, etc.)
  • Export necessary parameters, both discipline-specific as well as project defined (for example – status codes)
  • Clean out drafts, sketches, supportive lines.

Don'ts

  • Don’t export IFC and import it again to another native programme (because of loss of data)
  • Don’t export all objects in the model – set correct filters on exported objects (what categories should and what shouldn’t be there)
  • Avoid deleting objects (especially if a project uses BCF workflow)
  • Don’t export too fine geometry details – especially for the big models. IFC is not for visualisations or gaming
  • Don’t export schedules or legends
  • Never export all parameters – only those defined in the BEP
  • Never export references (only your own objects).

Consequences of faulty IFC export

Depending on what has been done wrong, there may be the following consequences:

  • Impossible to federate (wrong coordination points, rotation, levels)
  • Impossible to coordinate (the wrong objects exported, lack of parameters)
  • Hard to navigate (too heavy on details)
  • Unreliable to use as a reference (exported references, drafts)
  • A combination of the above – the model becomes totally useless 😉

Specific rules depending on the export purpose

Rules mentioned above help to set up a model and generally assure good quality model and export. Yet, there are numerous specific controls we want to implement depending on the purpose of the IFC export. As mentioned in the previous article – if I am a BIM Coordinator I need a slightly different set of parameters and objects than if I am (for example) a quantity surveyor. Below I tried to capture the most important rules and checkpoints to remember.

Reference model

We might want to export the model to have it as a reference. This purpose is very specific, driven by what discipline it is meant for. It can contain numerous different setups and rules. I’ve listed a few of the most popular with some important points. A small process remark: those models serve as internal Work In Progress models for a design team and should be kept visible only to them (as a part of internal CDE or hidden by access permissions).

ARC to STR (Architecture to Structural)

  • Eksport only raw construction model, including elements such as openings/black-outs, stairs, windows, doors, information about the material (concrete/wood/steel/masonry)
  • Reference/Placeholders to places where the heavier load is planned, like heavy machinery
  • Filter out unnecessary elements (landscape, furnishing, details)

ARC to MEP (Architecture to MEP)

  • Correct export of spaces (MEP engineers need those for calculations)
  • Placeholders for MEP equipment (air handling units, pumps, etc.)

STR to MEP (Structural to MEP)

  • Bearing elements (to plan a path for services)

Consequences of faulty IFC export

Too many unwanted details in a discipline model shouldn’t be a catastrophe – however, it will generate some more frustration on the engineer’s side. Definitely more dangerous is the incorrect export of spaces for MEP – the volume of the space is a basis for the calculations (such as fresh air amount). Some unnoticed mistakes might lead to insufficient capacity of services or, on the contrary, over dimensioning of the system.

When to perform this IFC export?

This export is meant for designers as a Work In Progress stage. It is relevant during the design phases: Concept and Technical Design. The architect’s office collaborates with all other design offices and they exchange IFC files (using a Common Data Environment platform).

Multidisciplinary coordination

In general, the most important thing is to let the BIM Coordinator do his work – check models for clashes and parameters. The models have to be clean and tidy and have all designed objects exported. Some of the most important items to check:

  • Export the zero-point object for your discipline
  • Check if the model structure is compliant with BEP
  • Divide model correctly
  • Export all your discipline elements
  • Export status codes
  • Don’t export all parameters – only those needed
  • Correctly classify all objects (slabs as slabs, stairs as stairs, etc.).

Consequences of faulty IFC export

If the model is overloaded with data it might be cumbersome to perform quality checks. That is especially valid for piping models. If they contain too many fine-detailed objects, the model becomes impossible to navigate and it will kill every PC, no matter how powerful. On the other hand, the lack of important parameters also will not allow the BIM Coordinator to perform his QA check in full. Insufficient coordination may lead to bigger design errors, leading to either comprehensive redesigns or later errors and reworks on the construction site.

When to perform this IFC export?

All designers perform this export and placed in CDE in a “Shared” state for all project participants. BIM Coordinator can federate all branch models (that can come from many different offices) and perform coordination. Depending on the project, the process of multidisciplinary coordination can happen weekly or bi-weekly.

Quantity Surveying

In this type of export, the focus is on quantities and materials. Classifications (e.g. Omniclass, Uniclass or, in Norway – Norwegian Bygningsdelstabellen) are also very handy for surveyors to create their cost breakdown structures. A common challenge for QS is that different software provides information about quantities in different places. It makes it harder to execute correct take-off. It is therefore important to agree on and use common properties for quantities for the whole project.

Some other points to remember:

  • Export quantities (Base Quantities)
  • Correctly classify all objects (slabs as slabs, stairs as stairs, etc.)
  • Export classifications (if used in the project)
  • Export parts as building elements
  • Check what view filters are set on and export correct categories and objects
  • Export material layers

Consequences of faulty IFC export

In the worst-case scenario, a significant lack in the contractual model can lead to change orders for extra works for multi-digit cash amounts. Another “popular” mistake is doubling the object types with different classification (harder to find during clash control) – then the price might rocket up.

When to perform this IFC export?

It depends on the contract type. If that is a traditional design-bid-build, IFC Export for Quantity Take-off is necessary for the bidding phase. If, on the other hand, the contract type is design & build or contract management and the delivery of the design happens gradually, then this export is handy for a contractor to order materials.

Model-based construction site

Performing the IFC export for contractors, the most important thing is to put attention on buildability from the model. That means in general to include parameters with responsibilities/companies (concrete construction, plumbing, etc.) and correct status codes (“For construction”). Oftentimes construction companies have their own specific needs for parameters or set up of the model.

Remember to include in your export:

  • Status codes
  • Discipline and responsible contractor
  • Control Area parameter (the building is often divided into smaller areas)
  • Discipline parameters necessary to build, such as installation height, fall, object type, reinforcement, etc.

Other handy parameters:

  • Floor-height reference mark (to have an easily accessible and common measurement point across the whole building)
  • Links to a database for delivery of Maintenance, Operation and Management documentation
  • Links to drawings/place with additional information (mostly a CDE directory)

Extra tip! It can be valuable to have a kick-off meeting about the IFC export with relevant companies (contractors or suppliers) to discuss their expectations and needs. In the end, they know best what they will need to build. Furthermore, some small adjustments in the settings of IFC export can give huge final results!

Consequences of faulty IFC export

Missing a type object or property set might even lead to a stop of work on the construction site. And sometimes the reason is very obvious and is in the IFC export settings – for example missing the responsibility parameter that the contractor is setting filters after. Another possibility is that, on design and build projects, contractors also perform the collision control and they can send claims if the model is missing on parameters or correct coordination.

Other risks are incorrect work execution, due to the flaws in the design documentation aka model. If the model is too heavy and hard to navigate, it may lead to reluctancy in using BIM Stations on site.

When to perform this IFC export?

With the start of construction works. The model has to be always updated, so such IFC delivery has to happen weekly or even more frequently (if some major changes occur).

Facility Management

This is the ultimate stage for every design model. It is up to the project to specify the amount of data provided in IFC versus PDF/Excel documents. Some might require e.g. a manufacturer or product information as property sets, while for others it is sufficient to deliver PDF documents. In the end, it is inevitable to avoid Maintenance, Operations & Management documents in the form of PDF (in my mind it’s pointless to describe maintenance within IFC parameter 🙂 ). Hence, we have to aim for clear structure and easy-to-find attributes linking models with database.

In Norway, it is popular to use TFM classification (Tverrfaglig Merkesystem, which can be translated as “Interdisciplinary Labeling System”) to code and identify each object in the model with a unique, machine- and human-readable string. Afterwards, this string is exported to IFC and serves as a connection between the model and the database. Other possibilities are COBie format or other country-specific classifications and standards.

Personally, I would vote for minimum data in the IFC model. Instead, supplied with a unique key attribute that links every object with an external database containing both operational data (maintenance intervals, manufacturer information etc.) and documents (maintenance instructions, schemas, etc.).

IFC as a handover format includes:

  • Links to storage for additional documents related to the object (can be replaced by the connection with external database)
  • Unique identifier to connect a model object with external documentation database
  • Objects classification supported by the chosen CAFM system (e.g. COBie, TFM, or other)

Consequences of faulty IFC export

Facility Managers might find no product information, nor any connections between model and delivered hand-over documentation. They won’t be able to search for correct suppliers if something breaks or for maintenance instructions and schedules. Incorrectly connected systems or objects with missing data might not give the information the managers are looking for. This, again, leads to frustration and manual searches in the database of all document files and folders, which kills the benefits of using BIM technology.

When to perform this IFC export?

This IFC export is performed at the project handover to the Building Owner. Yet, the data that defines this export might be already present in the model beforehand.  In Norway, many owners require to deliver facility management data and documents up to 3 weeks before the object is installed on-site. Thus they secure better quality data (fewer piles of documents at the very end of the construction phase).

Summary

You know now what data is important to include in your IFC export parameters set up. Remember, these constitute general checklists. Every project is different and so are requirements. It is worth checking what we need for your project. And if the requirements are unclear – discuss them. The sooner the better for the project data quality! It might look complicated at first, but most of the rules and positions from the checklist apply to the initial setup of the model and are defining the template for the IFC export. After doing so, delivering open standard files every week is a seamless process. I wish you were already there on your project!

Did you like that post ? Share it with others !

We spend a lot of time and effort creating all of our articles and guides. It would be great if you could take a moment to share this post !

Share:

Comments:

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments

Author:

Download BIM CASE STUDIES:

After reading this guide you will learn:

  • How BIM is used on the biggest projects in Norway
  • What were the challenges for the design team and how were they solved
  • What were the challenges on the construction site and what was our approach to them

Newest articles: