IFC plus Data Templates – the right recipe for interoperable data

We experience confusion in the market regarding how manufacturers should be using IFC. This is partly because ‘BIM community’ terms like IFC, IFD, IDM are still obscure to the general public and there are few real initiatives to use ‘plain language’ when describing everything BIM is.

In order to digitise product information, we need to communicate the characteristics as standard-based ‘properties’. Many manufacturers have realized this, but this is also where the confusion arises.

IFC, also called ‘the BIM format’, allows for the use of ‘properties’ and has embedded them within its logic. Logically enough, manufacturers come to the conclusion that providing their products ‘in IFC’ is sufficient for BIM. But it is not.

We will try to explain.

Espen Schulze

Espen Schulze, Group Vice President Research at Cobuilder

The Industry Foundation Classes (IFC) is a neutral, non-proprietary data format used to describe, exchange and share information.

IFC is developed to facilitate interoperability, but it does not itself guarantee interoperability.

While all sorts of data can be transported through IFC, the sheer flexibility of the format allows for multiple ways to represent the same product information. Without a unified approach this can lead to different implementers addressing same object in with incompatible representations, complicating verification and validation of set requirements.

For example, according to IFC, windows have ‘security rating’ as a parameter. According to the harmonized European standard (EN 14351-1) which covers windows, there is no such parameter as ‘security rating’ but instead three other: ‘explosion resistance’, ‘bullet resistance’ and ‘burglar resistance’, which are all in their own way vaguely similar to ‘security rating’.

This difference may look small and superficial, but it is actually much bigger – notions and parameters laid down by European harmonised standards find their way into Eurocodes and other regional and national design codes and thus travel across all stages of the construction process.

Construction products, mechanical, electrical and plumbing (MEP) systems and assets are subject to different technical, legal and market requirements and as such are described by very different properties (these can be based on the location, purpose or intricacy of the project). These properties should be part of the open data exchange format of the industry. This is why things are a little bit more complicated for IFC users today. Let’s look at some of the important considerations.

“If we want to capture all data relevant for manufacturers and product validation, we need to establish a link between the IFC model and manufacturers’ information.”

This can be done by developing a new methodology where IFC uses content from a data dictionary based on ISO 12006-3 (IFD). The content of this data dictionary needs to be organized into properties and data templates according to the coming standards prEN ISO 23386 and prEN ISO 23387. “

Let’s look at an example of a common building element: “window”.

As shown in the illustration below, the IFC entity does provide some good ideas of what the properties of an “IfcWindow” are, but  some of the properties needed in order to fully describe a “window” are not part of the IFC structure at this point.

Illustration showing the problem related to missed window properties with IFC

Firstly, to fully define a window for digital use one must have  information on local building regulations affecting window products. Secondly, it is best practice that there is a  credible source associated with properties, such as a product standard. I.e. the methods that properties are tested against.

European business semantics: how local building regulations and product standards can potentially enrich an  IFC data exchange.  

In some use cases data loss may occur if local and well-defined properties are not supported within IFC

On the other hand, IFC property sets also come with properties that are irrelevant outside the building information model. For example, the concepts ‘Status’ and ‘Reference’, which reflect respectively the current status (new, existing, demolish, etc) and the internal reference of an object inside the model. These are incomprehensible properties that IFC gives to the users.

While again IFC has the tools to carry the required data, there is a need for a solution for structuring data that is derived from the relevant local standards and design codes and holds the actual list of important characteristics that actors need to be aware of. These sources have already covered what is important for the different assets that comprise a construction project and satisfy both regulatory and practical needs.

So, what is the alternative?

There are two main international BIM standardisation committees today: the CEN/TC 442 and ISO/TC 59/SC 13. They are working on standards to support manufacturers to deliver structured interoperable product data for BIM.

These standards give the recipe for the alternative method where data is not lost in translation. By following this recipe, you will ensure machine-readable data and interoperability for all time to come.

  • ISO 12006-3 (IFD) specifies a language-independent information model which stores and provides information about construction works through the use of data dictionaries. It enables classification systems, information models, object models and process models to be referenced from within a common framework.
  • prEN ISO 23386 provides a methodology to describe, author and maintain properties in interconnected data dictionaries.
  • prEN ISO 23387 provides  concepts and principles for developing Data templates for construction objects used in the life cycle of any built asset.

Together these standards enable a methodology where all terms and definitions for business semantics within the built environment can be established, structured, translated and made available for all stakeholders within the industry.

“This methodology enables correct information from product manufacturers to be made available to exchanges specified in, and exchanged by IFC. “

It is important to understand that manufacturers store their data in various databases like PIM-, ERP-, CRM systems, etc. and that this data is used for several purposes: to show the advantages of their products, to provide better-informed solutions to their clients, to comply with regulatory requirements like CE marking and to comply with design specifications. We must emphasize the last one as it shows that these properties contained in data dictionaries are used by designers too.

IFC - the universal connection tool

European business semantics in action: the properties required by the Designer must be the same as the ones provided by the Manufacturer

The implementation of these standards – How it really works

Product data coming straight from the manufacturer can use IFC as transport format by linking or embedding data straight from these manufacturer’s PIM databases. It is highly important that the role of IFC and the role of a data dictionary is clarified. This must be achieved to provide consistent methodologies for software development to support the need for a seamless exchange of information between all stakeholders in BIM.

 Data Templates within a common dictionary framework solve the issue of what properties, test methods, and units describe a product according to a specific standard and do this constantly – regardless of semantic differences between terms in different contexts.

Once captured, this region-specific information must be exchanged between various BIM modelling software, currently none of which actually supports IFD dictionaries. Which is only natural – they are meant to handle model manipulation and information exchange.

That’s why CEN/TC 442 has also begun drafting a new work item that introduces an IFC-based exchange structure for product information and product requirements based on product data templates. The new standard will introduce a model view definition (a mechanism for filtering information in an IFC file) to be used by software applications to exchange product data in IFC.

This is also done today, but in the new model, the structure of the product data will be sourced from a Data Template in a data dictionary. This standard should close the gap between the business semantics described by ISO 12006-3, prEN ISO 23386 and 23387, and file-based exchanged as defined by IFC.

“In general terms, this means that manufacturers can use Data Templates to structure their data first and then when everything is properly arranged, relationships are created and unique identifiers created for all properties, they can use IFC to transport their data in different systems.”

From then on actors such as designers, specifiers, purchasing managers, contractors, etc., can use Data Templates to store their specifications and match them against manufacturers’ data.

A Data Template defined in a data dictionary is designed to handle complex product information.

A Data Template uses terminology that is both understandable and technically applicable by the local market.

The usage of a data dictionary makes the Data Template solution language-neutral, because the Global Unique Identifier (GUID) of the term is also tied to its relevant translations. For example, both ‘burglar resistance’ and its German translation ‘Einbruchshemmung’ are under the same identifier.

The practical result of this is that a German manufacturer can declare the proper product data in a comprehensible structure, and then this data can be validated against requirements in any language. IFC, while perfectly fitted as a transport and exchange format, it is made that much better by introducing data structures that are modelled within Data Templates.

IFC is the ‘how’ and Data Template is the ‘what’

Manufacturers do need to be aware of IFC. It is a great tool for collaboration, facilitating an open exchange of data during the construction process. As such, it is of use for manufacturers who want to get their precious product data straight into the model.

IFC is the ‘How’ to get it in there.

However, manufacturers also need to consider ‘what’ to get in there.For the ‘what’-magic to happen, IFC needs to be used together with the credible structure of the Data Templates.