IFC (Industry Foundation Classes) – Part 01 – An introduction for Autodesk Revit users

HELLO EVERYONE! After a year at Bond Bryan Digital and to coincide with our new website, it’s time I rolled up my sleeves and finally started blogging. For those who don’t know me my name is Emma and I’m an Autodesk Revit user. I’m a technician by trade and the more I used Revit over the years the more I craved structure to my information to get the best out of the software and my models. This is why I started to look at standards and ways of implementing them within Revit. In particular openBIM standards like Industry Foundation Classes (IFC) because I want my information to be as useful as possible to everyone who needs it, now and in the future. Therefore, combining the two was a challenge I couldn’t resist. It’s been a long road of blood, sweat and tons of testing to work all this out and dispel the myth that Revit cannot do IFC. We need as many people as possible creating good quality IFC exports from Revit and this blog will hopefully put you on the right path.

INFORMATION CHAOS Part of my role now at Bond Bryan Digital, as a Digital Information Specialist, is to untangle the processes connected to construction information. When you start to view it in the way we do; encompassing every discipline, every work stage, requirements, semantics, software and convention it’s in chaos. This is partly because its developed organically over many years in silos and we haven’t identified this, just tried to avoid it. This has caused us to trail further and further behind other industries, now we’re breaking down the silos and digitising it’s really highlighting how much of a mess we’re in. We can’t simply fudge our way out of it anymore as there is just too much for us to deal with. Computers need rules, they need consistency and we need to rethink our information for the digital age, for us this is what BIM is all about.

UNDERSTANDING INFORMATION Information authors play a very important role in the information ecosystem, they are after all the creators of the information starting from the dreaded blank screen. This role uses a multitude of technology and as a result I feel there are some important parts of the role which are perhaps being lost at times:

1. We need to change our mindsets towards our INFORMATION. Modelling in particular is not just about creating pretty geometry anymore; it’s about spending just as much time on the underlying information. In terms of Revit modellers need to spend as much time in schedule views as they do in 2D/3D views. This is why what we are doing now is completely different to the drafting and modelling of the past. We need to start seeing the beauty in well-defined and structured information.
2. Secondly think about the information which is being produced, it’s not being created for the sake of it. It will have a purpose therefore we need to make sure it meets that purpose and always consider the next user, put yourself in their shoes. We have to get out of this pass it over the fence and run-away mentality.
3. Thirdly and this is aimed at Revit users, the world of construction doesn’t start and end with Revit. It’s just a tool within a giant ecosystem of information, an ecosystem which needs to be supported by standardised ways of working across all work stages and disciplines so information can exist in its own right regardless of software. Therefore, think of information within its own right.

IFC – THE BASICS This is where IFC comes in. IFC isn’t software or strictly speaking a file format. It’s an ISO standard for the specification of digital construction information. One standard specification means that we have one clear way of structuring our information across all different processes. It also helps with the issue we have with interoperability between software, all the different platforms we use structure their data differently, which causes problems trying to move information from one to another. Having this standard provides commonality between platforms so information can be exchanged in a consistent and repeatable way. Image: Interoperability comparison between non-IFC and IFC exchanges It provides us with a base language and structure which allows us as Information Managers to make sense of the information and form a strategy around it. We have one consistent structure which gives a starting point in a world of thousands of variations. Trying to single-handedly digitise all parts of a facility during its life is no mean feat and yes IFC isn’t perfect but it’s had a blimmin’ good go and has assisted me many times. It started to be developed in 1994 and has been updated several times. The current version is IFC4 but for this blog series we will focus on the previous version IFC2x3 as it is still the most widely used by software. In a previous blog post we introduced our test files in which we pushed the software to create the best quality export it could. These files are jam packed with IFC goodness and one of these files was exported from Revit (yes Revit!). This blog series is going to go through the set-up of this file so you can see how it’s all done. Image: BBD Revit test file for IFC (click to enlarge) To start with I want to go back to the basics of IFC, this understanding is needed to be able to produce a quality export from Revit. Don’t worry we will be looking at this from a model author point of view and not a developer. I’m no IFC expert but I have spent a huge amount of time looking at this in the context of Revit and this is how I have made sense of it all in my head. For the IFC parts of this blog we will be referring to the buidingSMART IFC 2×3 HTML documentation website which is basically just a website to visualise and communicate the different parts of the IFC schema. Okay so this isn’t the most user friendly of websites and I have heard it described as an 80’s throwback (I like to think retro) but I’m hoping this blog will make the navigation of it easier. It does improve in the next version. As I’ve mentioned IFC is a specification for construction data, it’s a schema. Imagine being asked to draw a building but not as you would normally see it, but in terms of all the information which lurks within it. Information like the name of something, its properties and how this relates to the room it is in. That’s what the schema is, it’s like a big map where everything has its own dedicated place. Because everything has its place we can start to link things to other things or create a relationship.  As long as everything is in its correct place then the relationships work, and software knows where to look for it, because just like humans, technology isn’t psychic (well not yet!)

THE STRUCTURE At a very simple level the schema is made up of these three main items and we will go through each one. Image: Basic IFC components

ENTITIES Entities are like the main nodes of the schema this includes; physical elements like IfcWall, people like IfcActor or geometry like IfcSurface. They are basically anything with the letters “Ifc” at the front. In the schema these nodes form a complex family tree. Selecting one of these entities opens up more information relating to that entity. The animation below shows a very simplified version of the tree. It starts with IfcObjectDefinition and then splits into two. This splitting is very important. The objects on the left are occurrences and the objects on the right are the types. Image: Basic overview of the IFC2x3 schema

• Occurrences – These are the individual instances of products, these entities don’t have the word “Type” included in the entity name e.g. IfcColumn, IfcWall, IfcOutlet. In the Revit world these are the equivalent to instances.

• Types – These are the types of products, these entities do have the word “Type” included in the entity name IfcColumnType, IfcWallType, IfcOutletType. In the Revit world these are the equivalent to types. Note: in IFC2x3 doors and windows use the word Style instead of Type and a dedicated place in the tree.

Note, once you reach the IFC elements there is a whole other hierarchy, keep going down the tree to reach the entities you need as some may be contained within entities within entities. The last element entities in the hierarchy tend to be the most useful when working in Revit. Example: IfcElementType > IfcDistributionElementType > IfcDistributionControlElementType > IfcAlarmType That’s pretty easy to follow, the complication comes when you start looking at the entities and realise that the relationship between occurrences and types is sometimes not one-to-one, in fact you have three main scenarios:

• Some entities have equivalent occurrences and types like IfcSlab and IfcSlabType
• Some entities just have occurrences like IfcPile (in IFC2x3 there is no IfcPileType)
• Some entities just have types like IfcAlarmType (in IFC2x3 there is no IfcAlarm, for this you would move up the entity hierarchy and use IfcDistributionControlElement)

Always keep this in the back of your mind when working with Revit but don’t get too bogged down with it, there are some occasions where it becomes significant. One of the improvements of IFC4 is that this is much more consistent (so it does get easier!) On the schema website entities can be found by selecting alphabetical listing and then under Alphabetical index select Entities. This brings up the full list of entities in the bottom left of the screen. Image: Schema website – Entities (click to enlarge)

ATTRIBUTES An attribute is basic metadata about the entity and it where all other information about the entity can be attached, including direct and inverse relationships to other information. These vary between entities but there tends to be four attributes which are the first four listed for every entity:

• GlobalId – this is the Global Unique IDentifier or GUID
• OwnerHistory – Information about who created it
• Name – What the thing is actually called
• Description – What its plain language description is

On the schema websiteclick on an entity. The main window will bring up all the information regarding that entity. Scroll to the bottom and you will find listed all the attributes connected to that entity. You will see the four we have just mentioned but there are others listed which vary depending on the entity. The ones listed as ENTITY means there is a direct relationship, where the ones listed as INVERSE mean that the relationship is through something else. We won’t go into anymore detail about this for this blog series but there are two more important attributes we will discuss in the next two sections. Image: Schema website – Attributes (click to enlarge) Tip: You may have seen written down notation which uses a decimal point (or period) and wondered what it means. The point separates the different levels of the IFC schema. Example: IfcChiller.Name is referring to IfcChiller (the occurrence entity) and Name is the attribute associated to it.

PREDEFINED TYPES Having terms like IfcOutlet, IfcBeam and IfcCovering are great at a high level but it would be useful to be able to group objects with a little more granularity. To do this we have the attribute PredefinedType which you will notice in the attribute list in the image above. What’s great about these is that they have a predefined list. In data terms whenever we have a predefined list of information the values are called enumerated values, basically it’s a pre-defined list which you can choose a value from. These enumerated values can be located in two ways on the schema website:

1. Simply select the link associated to PredefinedType, in this example it is IfcOutletTypeEnum
2. On the left-hand side go to Enumerations, this will bring up a list of all the enumerated lists. Scroll down and select the one associated with the entity (sometimes there are more than one).

Image: Schema website – Predefined Types – Option 1 (click to enlarge) Image: Schema website – Predefined Types – Option 2 (click to enlarge) Image: Schema website – Predefined Types (click to enlarge) Either way will lead you to the same page which will contain the pre-defined list with some definitions against them. Where possible try and use a value which is already listed, this is a mindset to get into the habit of. Always question what an object is because I have found that our understanding of objects has developed in a rather random way. Think of objects purely in terms of their function and not what room they are in. Example WC cubicles are not Sanitary Terminals, they provide enclosure within a space (not dividing the space) and are made up of frames with panels attached. This is more aligned to a furniture system than a plumbing one. There are two enumerated values which are present in most of the element based enumerated lists, USERDEFINED and NOTDEFINED. USERDEFINED is to be used when the object you have does not fit into any of the predefined types listed. Note, you actually use the value USERDEFINED and there is a place to add the bespoke value as now described. The majority of predefined types are added at type level, for this you can add a bespoke value against the ElementType attribute. Where there is no type and the entity only exists at occurrence level you can add a bespoke value against the ObjectType attribute. NOTDEFINED is for when you don’t know what the predefined type is going to be yet. Example you know it’s a boiler but you have no idea if it’s steam or water. Note, you actually use the value NOTDEFINED.

PROPERTIES For element-based entities there is an attribute called HasPropertySets. This allows a property set (a group of properties) to be assigned to the entity. Within this property set are the individual properties which describes the entity further or describes its performance. In the schema there are already defined property sets and properties. Example for the entity IfcColumnType the property set is ‘Pset_ColumnCommon’ and a property is ‘FireRating’. Referring back to the schema website in the top left select property sets. Next select PSD Alphabetical Index this will bring up the complete list of property sets. Select the appropriate property set and it will bring up a list of properties. Image: Schema website – Properties – Finding the Property Sets (click to enlarge) Image: Schema website – Properties – Property Sets (click to enlarge) There are many property sets and properties contained within the schema but it’s impossible to cover everything which is required by all projects which is why IFC is flexible and will allow you to create custom property sets and link them to entities. Image: Custom properties A common mistake is that this is used as the first port of call before considering what’s already in the schema. A big problem we have at the moment is that we are exchanging IFC data models where things aren’t in the right place. In fact, rather than making use of all the predefined attributes and properties, custom properties are being created in an ad-hoc way for these. Therefore, when other software comes to look for it, the information which should be in the main schema (the large circle) is either not there or it’s incorrect because it’s a value which hasn’t been checked. You end up with this rather messy situation. Image: IFC data dumps This is generally what happens when you just click Export to IFC from Revit with no initial set-up. In the next blog we will start to delve into the workflows required to export IFC from Revit. Remember model viewers are just an interface to display the IFC schema and they can interpret the information in slightly different ways so I always recommend using more than one especially when doing testing.

SUMMARY Those who create and exchange information know we have a problem with moving information from one place to another which has been there since the 2D CAD days. Now we have 3D models full of information which is needed for many different uses, this problem has only become more complicated. IFC is a specification for structuring construction information and should be produced in line with specific purposes. Because it follows a set schema the information should be put in the correct place to ensure repeatability and predictability. This means that tools receiving the information know where to look for it and we can create core standard workflows/rule sets which can be used many times to analyse and check the information. Our technology is talking in a common language regardless of what it is and we don’t have to re-invent the wheel for every software combination. This blog has been a simplified overview of IFC which we have learnt about its structure, its terminology and where to find the information about the schema. In the next blog we will start to apply this to Autodesk Revit and go through the process of creating good quality IFC exports.

Emma Hooper, Associate Director, Bond Bryan Digital Ltd

Terms and conditions

All content provided on this Knowledge Hub is for informational purposes only. The owner of this Knowledge Hub makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. Bond Bryan Digital Ltd will not be liable for any errors or omissions in this information nor for the availability of this information.

Bond Bryan Digital Ltd will not be liable for any losses, injuries, or damages from the display or use of this information. We are happy for others to share our Knowledge Hub pieces through all social media platforms. You may include links to the original blog pieces and use part of the Knowledge Hub to then provide a link to the original content. However we would appreciate it if the content is not reproduced in full on other sites or publications without written consent being granted by Bond Bryan Digital Ltd.

This policy is subject to change at any time.