Most people know Industry Foundation Classes (IFC) as simply a file format that many pieces of software can export out to, but what actually IS it and what about makes some people so excited about IFC?
The existing documentation and official information is somewhat ironically not well structured or clearly explained, their intended audience is for knowledgeable and experienced data engineers only.
This blog post (and others to follow) aims to give a clear introduction into what IFC actually is for the layman. The intended audience for this post is anyone in the construction industry and I’ll be assuming zero knowledge of programming or information management. I’m also not going to be discussing BIM management processes or how to use IFC with any particular piece of software.
Along the way I’ll introduce important ideas that shape how IFC works but do my best to avoid terms like ‘kernel schema’, ‘data exchange requirements’, ‘conceptual layers’, ‘entity definition’ or ‘intra-domain exchange’. All of which appear quite scarily on the IFC introduction page.
I’ll be restricting definitions to just that which an AEC professional needs to know so if you’re an experienced software developer you’ll notice that some definitions may seem incomplete, but that is very much by design.
Let’s get started!
What is IFC?
A good starting point is simply to understand it’s name: Industry Foundation Classes.
But that’s obvious, isn’t it?! It’s the industry foundation classes! They’re classes for the foundation industry where people get taught about stabilising piles and diaphragm walls…
Well, not quite.
Let’s carefully step through these mysterious terms word by word to get a good understanding but we’ll begin at the end with Classes.
Classes is a term that comes from the software engineering world which may be a bit tricky to understand for those with a purely AEC background. In software engineering you can describe a thing as a class by listing what attributes it has and the type of value each attribute can be, it’s like creating a template that someone could fill in. I’ve intentionally used the very vague term things here because a class really can be any thing physically real or otherwise! Let’s look at a few examples.
If we were to describe a template for a Door as a class we could say it has the following attributes:
|ObjectPlacement||Coordinate Value (X,Y,Z)|
Note that this Door class (i.e. template) does not specify what the values are, only what type of values each attribute can have. If we follow this template we can then be confident that the Name of a door will ALWAYS be a piece of text, and that their OverallHeight attribute will ALWAYS be a number.
Below are two filled in templates for doors:
|ObjectPlacement||5000, 1000, 0|
|ObjectPlacement||4000, 1500, 0|
Because we’ve used a class as a template to describe them we know what type of value each attribute will be and we can start doing clever things, e.g. automatically checking that all doors aren’t below a certain height, or creating a list of names, or showing these doors at the correct locations in a piece of model viewing software.
If we hadn’t previously described the door as a class with attributes, the OverallHeight attribute for one door could have been written as “6ft 2 inches” and for the other door “2000mm”, which are in formats that, while perhaps easy for a competent human to understand, creates immense difficulties for computers to read.
As mentioned previously, classes do not necessarily have be physical objects. Below is a class for a generic Task:
|IsMilestone||True / False|
Again, we’ve restricted the types of values each attribute can be so if we had many filled in templates of tasks a computer could easily filter to find all tasks that have an IsMilestone value of True, or sort all Tasks by Priority. We can confidently do this because we know that IsMilestone will ALWAYS be either True or False, and that Priority will ALWAYS be a number. We don’t have to worry that IsMilestone might be Yes / No or that Priority is described as ‘Top’ or ‘Low’.
Let’s go even more non-physical now and describe a relationship as a class, say the relationship between a task (process) and a door which we’ll call an AssignsToProcess relationship.
|RelatedObjects||A list of Doors|
Here I’ve shown that the value type of an attribute in a class doesn’t have to be just something basic like a piece text, but can actually link to other things as well. For RelatedObjects the things will be a list of doors, each having the attributes that the Door template had and RelatingProcess is the single task which has the same attributes as the Task template.
From this class we can represent in a clear, consistent, and predictable manner how a list of doors relates to a particular task.
Making a relationship a class is actually a very clever way of being able to link things together. You’ll see this more in future blog posts.
As a quick summary, the Classes in Industry Foundation Classes refers to the software engineering idea that templates can describe what attributes things have and what type of values those attributes can be.
Back to the beginning of the acronym, the IFC website says the Industry is the construction and facilities management industries. Simple enough and no more explanation needed here.
The word foundation has a lot of uses but in this context, Foundation means that on which something is founded; it’s basis. Some examples taken from dictionaries: “this idea is the foundation of all modern economics”, “physics, the foundation of all the sciences”, or “The material provides a foundation for critical analysis”.
Industry + Foundation + Classes
We can now put together these definitions and get what the Industry Foundation Classes really are:
The templates that are the basis of things in construction and facilities management
At it’s core, IFC is really that simple.
The industry foundation classes definition lists a few hundred templates for things in construction and facilities management. Some brief examples of the sort of things it has templates for are:
- Windows, Doors, Walls, FlowControllers, PipeSegments, Cables, Grids, Zones, Systems, Circuits, Organisations, Approvals, Classifications, Assets, LabourResource, CalendarDates, Times, Vectors, 2D Lines, 3D Shapes
Using these templates you will be able to consistently describe pretty much any thing in construction and facilities management, from a single chair to full buildings and it’s maintenance needs.
Continuing from this we can now simply define that .IFC files exported from a piece of software are:
Filled in templates for things in construction and facilities management
When people use fancy phrases like interoperability or common data schemas all they really mean is that we’re all filling in the same templates.
Okay, I’ll admit that the way that some of the IFC templates are put together becomes a tiny little bit more complicated but honestly it’s not actually difficult to understand once explained simply. I’ll even now promise that some of these things that initially appear to be complicated in fact makes it easier not harder to get your head around how IFC works.
Why is IFC so great?
Ever tried to understand how the information in Revit is put together? Or from Tekla? Or even a file from Forge?
There’s little point even trying because unless you work for the respective companies you aren’t going to be able to. Why? Simply because these companies keep the templates they are using as a basis for things in construction and facilities management a well-kept secret.
If we don’t know what templates they are using then we don’t know what attributes things have or even what type of values those attributes can be. We can’t even be 100% sure what the names of the templates are. As you can imagine this makes bringing together information from many places extraordinarily difficult and in some cases impossible.
IFC on the other hand? Well, all the templates are completely free to read online and free for any individual or company to make use of in any way they want. In addition, no one company owns and controls these templates and their ongoing development is managed by bringing together a broad range of people from construction and facilities management. This is what makes IFC great.
I’ll give one last example: if architect A fills in an IFC door template and architect B fills in an IFC door template then I know with near certainty what attributes those doors will have and what types of values those attributes will be by looking at the free online definitions. This predictability is what allows computers to take over many previously manual tasks and increase productivity.
(I’ll need to be clear that I’m not saying everyone needs to start filling in IFC templates by hand. A very legitimate process is to take a Revit file, Tekla file, or another BIM file and convert their secret templates to the freely available and widely understood IFC templates by exporting to an IFC file.)
So in my first blog post I’ve described IFC as essentially a list of templates that can be filled in and saved as a .IFC file for others to read and it’s great because all these templates are free to use.
In my next post I might go into a bit more detail about how these templates are actually described and connected together.
If you have any questions or comments or areas around openBIM technology you’d like me to blog on, please let me know below or on Twitter @TimDaviesUK!