IFC is a global standard for data exchange in the building industries. IFC is both a common data model and an open file format. Building industry professionals can use IFC to share data regardless of what software application they use to get their job done. Similarly data from one phase of the building lifecycle can be utilised in a later stage without the need for data re entry, custom import interfaces or proprietary plugins.
IFC is maybe the main enabler of collaborative lifecycle BIM. Its only real alternative today is standardizing on a proprietary format as described here. Its use is required by owners in more and more projects globally. It is an important consideration for any handover strategy. At the same time IFC is a subject to some misunderstandings and multiple “variants” as we will see later in this article.
Read on and we will walk you through what you and your team should know about IFC. The article should be relevant for anyone required to generate, share, handover and maintain building data now and in the future. We hope to clear up the misunderstandings and lay a groundwork for discussions and decisions in your team.
Why IFC and why now?
Use of BIM tools is on the rise. To reap the benefits of BIM information exchange is required. BIM execution plans typically state requirements for this exchange. Building owners should be able to state their requirements. There is varying quality of the importers and exporters of the BIM tools today. Most require custom settings. IFC has strengths and weaknesses. In certain areas and in certain settings it really shines. In other areas use of IFC could be counterproductive. If you are reading this you are likely to either require the use of IFC or bid on project where the use of IFC is required. To be successful your team needs to go beyond a basic understand of the IFC standard and keep up to date on the developments surrounding it.
IFC as an exchange format - what do the model exports contain
IFC models contain a structures combination of geometric and non-gemetric data. This data can be displayed, analysed and modified in different ways in multiple software applications
The IFC models contain building geometry and building data. They include “all” or a subset of the information that is contained in native BIM files. Transforming and exporting the native data into an IFC file is a way to transfer data from one application to another. The exchange format is open, free and well documented. By providing ifc export and import interfaces that conforms with the IFC standard(s) the application vendor are able to provide interoperability with hundreds of other BIM tools and domain applications.
IFC use in design and construction
The use of IFC is today most common in the design and construction phases. In design the main use are design visualisation and clash detection. The design team can now reference or merge discipline models regardless of originating application the same way they exchanged DXF files to merge (XREF) CAD files in the past (or overlay blueprints before that). In addition to referencing models from other disciplines IFC files are used to import data from one application to another. BIM objects with geometry, data and schedules can be exported from one originating application and then importing into another to continue design or analysis. In the transfer process there will be some loss of data and object intelligence as we will see later in the article.
During design and construction each discipline typically have their own model. The models are merged or referenced for design and production coordination tasks
Having a virtual building model in an open format has also been big win for contractors that can view design intent in easy-to-use programs and do takeoffs and scheduling based on the virtual building model.
In addition to the “integrate between bim tools” scenario a host of speciality tools that utilise the IFC format are evolving. Examples are quality assurance tools, model viewers, schedulers, punch list applications etc.
IFC as a data model - What is the structure of the IFC model
We already stated that the model contains both geometric (3D and 2D) and non geometric data about the building project. Technically the schema defines an entity-relationship model based on “EXPRESS”. To further explain we will use a door as an example.
A door element is defined as a door in the system. Being a door it is already classified in the building domain. There are type definitions that lets similar doors both in the same project and across different projects share properties. Both the type and the instance can have attributes and properties attached to them. This is important. You attach the common information, like the maintenance instruction, model number, size etc to the type but you attach the specific properties like serial number, installation date, condition etc to the instance.
The properties themselves has a specific structure. Properties are normally grouped in property sets. Some of them are defined in the IFC standard, some are defined in bim execution plan etc. If you want specific O&M data for operations in handover this is one place to put them /look for them
IFC also have other ways of grouping elements. Most notably are systems that are used to group building elements and components that are working together. This is especially important in MEP models where systems like water supply, air inflow etc
IFC also defines relationships between the building elements. Some of the relationships are used to build the connections we already talked about, systems, types, property sets etc. Other relationships describe how the building components become buildings. The relationships include the spatial structure (how the site is composed of buildings, building storeys, rooms(spaces) and how the spaces are grouped into zones. Other relationships are connecting the location of elements to this spatial structure, something that is very important for Facility Management. Relationships can also be external pointers to tasks or documentation with an external address
IFC as a file format - alternative representations
IFC in its common form is a plain text ascii file. The schema defines how the plain text are turned into object aggregates with relations and type inheritance. Even if the information is kind of readable it is software applications that are the creators and consumers of the file contents. The format of the IFC file itself is based on an ISO standard (10303-21) called “STEP-file”
The plain text contents of an IFC-STEP file
IFCXML file format uses the same data model as the “normal” ifc format but instead of an ascii representation the file is represented as a xml document. Having this xml document could mean easier machine to machine data exchange. It is also easier to query the model directly. However those uses have not gained widespread adoption and we do not see much of this format - at least yet.
As both the FC and IFCXML files are text files and they contain a lot of data they are prime candidates for compression. Using a compression tool like “zip” or “rar” you will typically see around 80% and 90% decrease in file size respectively. IFCZIP has been standardized as file format where certain compression algorithms has been used and only one ifc (or ifcxml) file is included. It is our experience that the ifcxml file format has not gotten big adoption
Schema versions
The IFC schema have been released in different versions and is constantly evolving. The two version that are currently relevant are IFC 2x3 and IFC 4 (the naming of these two are a bit confusing so let me explain. The history of the previous releases have been 1.0, 1.5, 1.5.1. Then there were 2x, 2x2 and 2x3. Following this the newest release could be named IFC2x4 but instead they simplified naming of current version to IFC4 and then the upcoming major version to IFC 5).
Even if IFC 2x3 is the previous release it is still the version we are seeing most in use for now, and probably will be the dominant version in the near future. The reason for this lag is partly that it is taking time for the major BIM tools to implement support for this new version. Also a lot of the current ongoing projects are using BIM execution plans stating that the exchange format should be IFC2X3. IFC 2x3 contains some limitation and has gotten some critique. These items are being addressed by buildingSMART in the following releases (IFC4, IFC5 and beyond).
IFC4 is extending support for geometries and parametrics, extended the building services and structural domain and include a simple XML format(more on formats later).
IFC5 is the new coming major release. It is currently in the early planning phase so we have no expected delivery date yet. The main driver for this release is expected to be further expanding the parametric capabilities and the inclusion of the infrastructure domain.
IFC MVDs - smart filters
The goal of IFC is to describe a common schema to exchange all data that could be exchanged between bim tools. However not all data needs to be exchanged every time two tools need to interoperate. The information required is dependent on the process the exchange is part of. This subset of the schema is called a Model View Definition or MVD for short. MVDs are best described by examples
MVDs for IFC2X3
The IFC2X3 Coordination view (version 2) is the most common export format in use today. The use case for this MVD is quite generic. It is used to combine models for visualisation and clash detection. As you will see below this model view has been split in two to be more specific in IFC4.
It is important to note that this MVD has optional add-ons and dependent of the bim tools setup these add-ons are not necessarily included by default
Space boundary add-on view adds “building element to space relationships”. The purpose of this add on is originally to support thermal and energy analysis, but our experience also show that this is needed to be able to locate elements in rooms when identifying objects that require operations and maintenance.
Quantity take offs adds ability to export base quantities for all spatial, building, building service and structural elements
The 2D annotation view supports additional 2d element representations and annotations. This can be important for generating proper floorplans
Export to IFC settings from a common BIM tool. The export settings are aligned with MVD specifications and tweeking the settings will affect the contents and structure of the IFC export
Other mvds for 2x3 is
The structural analysis view that export a structural analysis model from one structural analysis application to another
Basic FM handover view - this MVD and its relation to COBie will be covered in a later separate post as it is so central to the FM and handover domains
MVDs for IFC4
For IFC4 the very generic IFC2x3 Coordination view 2.0 has been replaced by two MVDs to distinguish between two different main use cases
IFC4 reference view - this subset of the schema is suited for workflows using reference models. The models are flowing in one direction in the workflow. The model is generated by the designer in the bim tool. The subset of the model is exported. The consumer use the data to support his work process (design coordination, clash detection, visualisation, quantity take-off etc). However the consumer will not make edits to this exported model but rather issue change requests using BCF or similar if edits are required.
IFC4 Design transfer view - this subset of the schema is intended when the consumer of the transferred model is required to manipulate and edit parts of the model either to continue the design or to “play with” different edit options e.g. after a clash has been detected.
Why MVDs are important
You get what you ask for. Using a subset trims down models and make them more efficient and picking the right one ensures you have the information you need. Using a specific mvd (especially reference view) are also needed if legal reasons require that the full design model are not exposed and the originator needs to protect their intellectual property. Owners that want as built/ as designed models on the other hand should require the proper design transfer view/ and or FM handover view to be able to utilise the data in later phases, eg. when analysing structural effects of a planned major work.
IFC as a general archival format
Many of the characteristics of IFC already mentioned makes it a good candidate for an archival format. IFC is an open and free format, it is in wide use globally and supported by a wide range of applications. It is now also an ISO standard. The format is also quite stable with few updates and it aims to be backwards compatible by mostly adding and fixing stuff in newer releases. And by saving the schema along with the ifc export itself there is a good chance that a lot of the information in the model can be retrieved any time in the future.
IFC as an “as built format”
The good aspects of the IFC format described above means that the information will not deteriorate. When considering IFC as an “as built” format however we also have to consider some challenging aspects of IFC. However there is currently a data loss in the export of the IFC data, at least for the current versions and mvds in use today. This means that when using current IFC exports in the future an architect or a structural engineer will have “dumber” objects when importing into bim tools when comparing to importing the native version of the as built architecture model or the as-designed structural model.
To mitigate for this issue we advise owners to require and archive both native and IFC exported versions of the as-built models at project completion to use in later refurbishments and major works. Generally the native model is expected to have the highest value in the short term since it can be used directly without data-loss in BIM tools for some version upgrades of the platform. Long term however the IFC model is expected to have more value as the native model is less likely to be of any use the longer out in the future we look.
It is important to note that with the advances in the IFC format will make it better and better as a handover format. When the design transfer view gets fully supported for parametrics the need for the native model may not be there anymore and the refurbishment project have a bigger choice related to use of bim tool (e.g. design the model in Revit and do major works using Vectorworks.
IFC as a handover format
These four images show different views of the same model
IFC has a good foundation for being a good handover format and form the base of a integrated handover strategy. The BIM models in their native formats already have a lot of data both geometric and non geometric (properties and quantities). With a properly up to date model-export the building owner and facility manager gets a virtual representation of the real building that can be used to support FM processes as we have described in earlier articles. In addition the structure of the models and the objects themselves act as great placeholders to collect additional O&M data needed for the handover phase. The standardisation efforts around IFC and COBie also mean that tools more suited for collection than BIM tools for data collection and pre-handover o&m planning are emerging.
At the same time it is important to note that the format used is just an enabler and one step in the right direction. The important part for a handover process is that the elements in the models that require operations and maintenance are updated with specific and correct data to have value for the owners and operators
Summing up
IFC is a data model that is used to describe building data and geometry across building disciplines and across phases of the building life cycle. IFC is both a de-facto standard and an ISO standard. The format is open, has wide industry support and is backed by a non profit global organisation. It is a common requirement for BIM interoperability and most of the tools in use in your design and construction projects already support exporting/ importing the format.
An IFC file is an export from a bim tool that is intended to be imported into another BIM tool, either for design coordination, phase handover or for similar data exchanges that require interoperability. There are different version of the schema. Current version in widespread use is IFC2X3 but expect version IFC4 to gain adoption in the coming years.
When exporting data to an IFC file only a subset of the BIM model is exported. When requiring, producing or consuming IFC files it is important to know the purpose and contents of the MVD in use/ to be used and how it relates to the import and export settings of the BIM tools and servers in use.
IFC is not currently solving all issues in interoperability but work is underway to close the gap.
There is too little knowledge in the market about all the details of the format and specifications in BIM execution plans are either too general or too detailed.
We hope to have brought some clarity into this complex topic and are welcoming comments and questions below to further gain understanding of this important topic. We will do our best to answer questions and/ or do follow up posts to clarify related issues.
