Secrets of the IFC format

Secrets of the IFC format part 2

In the previous article “Secrets of IFC format”, I have mentioned the structure of relationships in the IFC schema. This structure reminds of a simplified family tree with parent and child items, which are related, and also… inherit attributes. How does it work? Where do these attributes come from? I will try to explain this in the following article.

1. Classes in IFC schema

  1. In the IT world, each item/object may be described as the so-called class with specified attributes and the type of a given attribute. I have written about this in the previous article “Secrets of IFC format”:

The attributes assigned to them (objects) are also important from the engineer's point of view (the door has a dimension, the material it is made of, its position in space). IFC describes each element as a class. It may seem a bit confusing, but in a nutshell, the idea is that each element has a list of attributes (name, material, position, dimensions) and the type of attribute value (text, number, coordinates, etc.).

It means the IFC creates a kind of template for each element having a precise definition along with a list of attributes (of course, the attributes are also precisely defined).

1.1 Classes as attribute template

How can we imagine this template as a class in the simplest way? For the door object, it would be as follows: 

IfcDoor attribute template
Example attribute template for the IfcDoor class

This type of object description gives us confidence that regardless of which program we will use to generate the IFC model, the object attributes will always be in the same format, therefore “Name” will always be a text, and “Height” will always be a number.

Filled template of the door object looks as follows:

IfcDoor attribute template filled
Example of a completed template attribute for the IfcDoor class

The classes are not necessarily a physical object, such as a door (IfcDoor) or a wall (IfcWall). It may also be a task (IfcTask), described through the attributes, as presented below:

IFCTask template example
Example attribute template for the IfcTask class

Again, we know for sure that describing the class through the attributes as well as the value  type, the IsMilestone attribute will always be Yes/No attribute (not for instance maybe, almost, 0/1, etc.)

The IFC schema also has more abstract classes, such as “relationships”, which describe the way of connecting objects with the use of attributes.

For more information on “relationships” in the IFC scheme, see the following graphic:

The IFC schema also has more abstract classes, such as “relationships”, which describe the way of connecting objects with the use of attributes.

 

Therefore, it is possible to connect tasks (Task), for example, phase 1 with building elements – Walls Level 1 (all walls from the first building level).

The IFC schema has several hundred defined classes. Hence, it is possible to define almost anything in the project (what is more, we can add additional properties or sets, but about this later).

The name IFC Industry Foundation Classes, then, refers to the objects (described as classes through attributes and the type of a given attribute) being fundamental in the construction industry and building management.

When it comes to exporting a model from the native program (Revit, Tekla, Archicad), in fact, it is about “filling” the class templates with the values of the appropriate attributes by this program.

The most important thing is that each program fills the same template, with the same types of values, hence we know that the exported model is universal.

2. Attribute inheritance

In the previous article, I have also noted that the IFC schema “(…) isn’t composed of a flat structure with separate 

In this type of a tree, it is possible to indicate “parent” and “child”. And there are many features we can inherit from parents, such as eye color, hair, height, character…

It means that the attributes of the templates in the IFC schema may be transferred from “parent” to “child”.

Before I start discussing the schema, I will use the example from everyday life to explain how the attribute inheritance works.

Imagine that you have a vehicle with the features (attributes) such as:

  • Weight (1500 kg)
  • Color (black)

This vehicle may be a car with the attribute:

  • Brand (Audi)

The car may be a station wagon version and it may feature the following attribute:

  • Capacity (200 kg)

What does the inheriting of attributes mean in this case?

The station wagon has the capacity and inherited attributes such as “brand” – Audi, “color” – black, and “weight” – 1500 kg. The car’s attributes are: “brand” – Audi, “weight” – 1500 kg, as well as “color” – black. However, it does not feature “capacity”. Whereas the vehicle has “weight” and “color”, but it does not feature “capacity” or “brand”. 

The inheritance of attributes in the IFC schema is similar.

Let’s have another look at the door template:

Atribute inheritance
Attribute inheritance example from everyday life

The inheritance of attributes in the IFC schema is similar.

Let’s have another look at the door template:

And now, let’s compare the above template with the similar one representing a slab (IfcSlab).

In both cases, the attributes are repeated both in the door and the slab template.

By analogy to the vehicle example, both templates have a master template – in the schema, it is IfcBuildingElement.

This template will contain all attributes of the door and the slab.

IfcBuildingObject

Thus, how is “inheritance” implemented in the IFC schema?

The attributes in the template are entered only once. If an attribute is repeated in a “child” template, it is omitted to avoid duplicating the same attribute.

Therefore, in line with the above principle, the door template (IfcDoor) looks more or less like this:

IfcDoor

In turn, this is the slab template (IfcSlab)

The graphic below presents this process in a more accessible way:

In general, the final result is as if we would write all these attributes again. Eliminating the whole string of words means that if we would like to change an attribute, we would only have to do it in one position. It is useful, isn’t it?

3. IFC Schema - Family tree

If you visit the buildingSmart website and look at the IFC schema specification https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/FINAL/HTML/, you may feel a bit confused seeing this IfcDoor class graph:

IfcDoor inheritance graph
Example of an IfcDoor class Source: https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/FINAL/HTML/

But if I present it in a simplified form as a family tree, the scheme seems more understandable and transparent and the line of relationships between “parent” and “child” is much clearer.

Summary

Now, you can see, those apparently different elements in the schema are similar. The two so different classes, like object (IfcObject) and process (IfcProcess), in fact, share many mutual inherited attributes.

Each class in the schema has the Globally Unique Identification (GUID), owner history, name, and description inherited from the IFCROOT template, which is superior to all template classes.

IfcRoot graph
Source: https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/FINAL/HTML/

The use of standard, universal templates makes the information, that is passed on and used in the construction process, easier to control and more predictable (after all, the most important element in BIM is I – information). Especially, if we want to automate, improve, and accelerate the processes with the usage of computer software. The fact that attributes in the whole schema (family tree) are inherited means that we are sure that the attribute format for different classes will always be the same. It will not happen that the door height will be expressed as 120 cm, and the window height as one meter twenty.

Another example? Imagine that you are using the program to create door lists. The program groups them using the Type attribute (IfcObjectType) – e.g. Door Type1, Door Type2, etc. It is easy to notice now, that the same program will easily create a list of windows (IfcWindow) or walls (IfcWall), because their structure, as I have written above, is very similar thanks to universal templates and inheritance of attributes. I hope this article has brought you a little closer to the IFC schema, its universality, and a wide range of uses. What about you? How do you use IFC models? Share your experiences and thoughts.

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:

Share on facebook
Share on twitter
Share on linkedin

Comments: