In the last post we looked at how the IFC templates are organised and learned that they aren’t a flat list but are actually connected together like a great big family tree. The child templates would “inherit” attributes from their parent which allows us to reuse attributes which increases the predictability of how data is formatted.
This post is about how the completed or filled in templates connect together to form a construction and facilities management project.
Unlike the IFC templates a building shouldn’t be thought of as only a simple tree. I know what you’re thinking, software like Navisworks or Solibri often show a big tree structure from Site to Building to Building Storey to Parts. This is also how many other pieces of software force you to think of a building.
This might be a useful way for architects to think about buildings, but it’s hardly optimal for building services engineers who have systems that span many levels, or structural engineers who need to think about loads transferring across a building. And for the likes of quantity surveyors or planners this tree approach makes even less sense.
Fortunately IFC allows you to connect parts of a construction and facilities management project in many different ways to suit the way different disciplines think about buildings.
In fact, construction and facilities management projects are all about things being connected. Some connections are obvious and physical, such as those between two bricks with mortar, two pieces of steel with a bolt, or a pipe and a fitting with some solder.
Other connections concern management, the connection between a programme of works and the physical parts it refers to, or between an operative and what they’re installing.
Some connections might not even appear to be connections at first, such as the connections between a thing and its properties, a room and the zone it belongs in, or a physical item and the catalogue reference it is ordered from.
All of these types of connections, or Relationships, can be made in IFC.
In IFC the template for a relationship is completely separate from the things that it connects together. You can think of IFC Relationships as like the mortar between 2 bricks.
The bricks themselves don’t lock into each other and the bricks don’t actually change themselves. Most of the time you can scrape off the mortar and the brick will be basically unchanged. The bricks are unaffected by being connected via the mortar.
We will see that in IFC we can use this idea of digital mortar with more than just physical objects.
When we create lots of these Relationships and connect together different parts of a construction and facilities management project we don’t end up with a tree, but something more like a web. Lots of different parts connecting together.
Let’s have a look at some of the IFC Relationship templates we have available to us.
As we know from the previous post templates are formed in a hierarchy. Directly underneath Root is Relationship, and under Relationship are the 5 main types of Relationships we can have in IFC:
These largely sound like different words for the same thing so we’ll take a closer look to understand the subtle differences.
This is used to describe when someone or something is going to actually use something else. It generally means some work is going to be carried out. For example, you can assign a person to a pipe, you could assign a task to a wall, a process to a cable tray, a duct to a system, or a cost to a task.
When you associate two things together it usually means they have quite a loose relationship that doesn’t really affect how the object works. For example you can associate an object with documents (installation manuals, O&Ms, warranties etc), with classification systems (Uniclass, Omniclass etc), and with approvals (permit to work, design validation etc)
All types of connections that don’t strictly belong as one of the other 4 types become a simple Connects relationships. Some examples include: Connects Ports, which connects two M&E services parts together, such as the ends of two pipes. Services Building relationships links an M&E services system with the spaces it serves. Connects Elements is the traditional physical connection such as mortar between two bricks. Covers Spaces specifies the walls, ceilings, or floors that make up a room.
This is probably one of the oddest terms in IFC. The word comes from compose, meaning bricks compose a wall. The opposite being a wall decomposes bricks. You can think of Decomposes as meaning “made of”.
So a Decomposes relationship is just between one thing and all the things it is made of. It can go many levels up and down too.
A wall decomposes (is made of) bricks. A building decomposes (is made of) walls. A site decomposes (is made of) buildings etc.
A Defines relationship links an object to something that describes what it is. The two specific examples in IFC are a relationship that links an object to its catalogue description, i.e. Its type or family in Revit-speak. And a relationship that links a set of properties to an object.
Why are relationships important?
As mentioned above, buildings are the result of many different products, people, and processes all being connected together. They’re never a simple list or hierarchy but a big complex web. If it isn’t managed properly it becomes very easy to get tangled in this web, causing confusion, and wasted time. What IFC offers is an ISO standard digital way of managing these connections, so computers can take over many of the manual approaches taken when cross referencing information. This can reduce time and increase consistency, and therefore improve productivity.
I’ve not actually gone into much detail on the specific IFC template details in this post, this is because Relationships will be mostly handled by software and it’s unlikely you’ll have to ever manually create an IFC Relationship. However, the important idea is that IFC Relationships act as digital mortar between things to create a web of information that ultimately forms a construction and facilities management project.