Is IFC equipped to structure manufacturers’ data?
It would be an understatement to say that there is some confusion in the market regarding how manufacturers of products and systems for construction works should be using IFC. This is partly due to the fact that ‘BIM community’ terms like IFC, COBie, IFD, IDM are still very obscure to the general public and the initiatives to use ‘plain language’ when describing everything BIM are still in their earliest stages.
Manufacturers have increasingly begun to understand that in order to digitise product information one needs to communicate the characteristics as standard-based ‘properties’. Here is where confusion starts as IFC, which is sometimes equated with ‘the BIM format’, allows for the use of ‘properties’ and has embedded them within its logic. Here is how manufacturers come to the conclusion that providing their products ‘in IFC’ does the trick for BIM. The spread of this notion is exactly why clarification is needed and this article is aimed at providing some guidance regarding how manufacturers should understand IFC.
The Industry Foundation Classes (IFC) specification is a neutral, non-proprietary data format used to describe, exchange and share information. IFC was developed to facilitate interoperability, but it does not itself guarantee interoperability. This means that all sorts of data can be transported through IFC, but does not mean that this data is structured, accurate or fit for purpose. IFC is an exchange format – therefore it should not be used to organise, qualify or structure data. For clarity this can be summarised by the following statement:
IFC is equipped to transport the data of the manufacturer, but not to structure this data using the built-in schema, with entities, types of entities, property sets and properties. It is necessary to establish the link between the IFC model and manufacturers information by developing a methodology where IFC uses a data dictionary based on ISO 12006-3 (IFD) together with properties and data templates according to the coming standards prEN ISO 23386 and prEN ISO 23387.
Yes, an IFC entity does provide some good ideas of what the properties of an IFC_window are, but it does not provide the full extent of the properties needed to describe a window. Neither does it provide a credible source of such properties *(such as a product standard), the methods that properties such as ‘U-value’ are tested against or any further information. This means that if a specifier adds a window with 20 properties in an IFC model and the IFC format supports only 4 properties within its logic all other 16 properties will go into a ‘custom generated’ property set. The properties in this property set will not be treated separately, which can be problematic if the IFC export is to be used by any further system. Also, no one guarantees that the data held in this diverse property set is properly defined. Here is where IFC does not support interoperability to its fullest.
What is the alternative?
The two main BIM standardization committees, CEN/TC 442 and ISO/TC 59/SC 13, are together with buildingSMART working on standards to support manufacturers to deliver structured interoperable product data for BIM.
· ISO 12006-3 (IFD) specifies a language-independent information model which can be used to store or provide information about construction works. 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 dictionaries.
· prEN ISO 23387 provides a general structure for data templates for construction works entities.
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 manufactures store their data in databases like PIM-, ERP-, CRM systems etc. and this data is used for several purposes. Manufactures data can use IFC as transport format by linking or embedding data from these 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.
IFC is already equipped with a mechanism where references can be made to dictionaries, and where data structures from prEN ISO 23387 can be supported. Outsourcing the business semantics to dictionaries will provide consistent and reliable information to all stakeholders using this approach.
The most important data dictionary on the market today is buildingSMART Data Dictionary (bSDD), developed by buildingSMART International. It is regarding by many to be the main provider of global unique identifiers (GUIDs) for business semantics, and it is developed to provide the single source of truth for the global construction industry.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.
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 has several main advantages over IFC when it comes to handling manufacturers information.
It uses terminology that is both understandable and technically applicable by the local market. 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 harmonsied standards find their way into Eurocodes and other regional and national design codes and thus travel across all stages of the construction process. So what happens when a designer has to set up requirements for all three parameters, but the software provides him with only one? What happens if an AIR requires the builder to specify ‘security rating’ for windows?
Do we need all that guesswork?
Such discrepancies in terminology force people to make subjective assumptions on what the other side means, and this is very bad for a digital process. The construction industry has a habit of using certain terminology and information travels along its lines, and a Data Template allows people to use the precise terms they need. Furthermore, the usage of a data dictionary makes the Data Template solution language-neutral, because the GUID of the term is also tied to its relevant translations e.g. 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 (provided they are also built on the basis of a Data Template. IFC, while perfectly fitted as a transport and exchange format, is not good for this role.
Data structures in a local context
Another issue with IFC and specifically the properties listed in ISO 16739, besides not being understandable by the wider audience, is that they are nowhere near an exhaustive list. They are just an abstraction of what is generally declared, but same as with the meaning, in no way represent the requirements of the local industry. Important properties like ‘yield strength’ for steel members or ‘U-value’ for insulations either are missing, or hidden under incomprehensible attributes, that make sense from a coding perspective, but are totally obscure to people coming from construction.
On the other hand, IFC property sets also come with properties that are irrelevant outside the building information model, like Status and Reference, which reflect respectively the current status (new, existing, demolish etc) and the internal reference of an object inside the model. While again IFC has the tools to carry the required data, a DT derived from the relevant local standards and design codes is 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.
IFC is the ‘how’ and Data Template is the ‘what’
The conclusion of all this is that manufacturers do need to be aware of IFC. It is a great tool for collaboration facilitating 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. But that’s all it is – ‘how’ to get it in there, not ‘what’. In order for the ‘what’ magic to happen, IFC needs to work hand in hand with the straightforward, credible structure of the Data Templates.