Following my last detailed and highly technical post about model creation related to IFC, I received a comment on the blog piece from fellow Graphisoft ARCHICAD user and expert, Link Ellis from ArchiLINK. Link was seeking more of an overview to how IFC works for his clients. I think its fair to say that many people would like this, including me. Unfortunately I am not aware of any document that tackles this at present. It is something I have raised and we have discussed at buildingSMART UK Technical Group meetings. Hopefully this will become available in due course. In the meantime I will continue to share my IFC understanding (particularly related to ARCHICAD) and thoughts through this blog.
My last post was probably more useful if you understood the need and had begun to explore IFC, but in this post we will take a step back. Setting aside the general overview of how IFC works, I do think it is important to understand why all companies should begin to consider IFC in their workflows including those small companies who are yet to collaborate with others. This was Link’s other main query in his comments on my blog piece. It is almost irrelevant to understand how IFC works if you don’t understand why you need to even consider using it in the first place. So I will try and put down my thoughts on the “why?” here.
The need for neutral file formats
The need for neutral file formats is dependent on what software you need to exchange your models with. If you are working with someone using the same software then using a native file format makes sense. However, as BIM grows both in the UK and internationally it becomes inevitable that you are going to have to exchange a model with someone not using your brand of chosen software at some point in the future. Even where you can get the design team (architect, structural engineer and MEP engineer) using the same software you will inevitably need to collaborate with someone else in the supply chain using another solution. I’m not going to say that is not possible to deliver an entire BIM project with a single software companies solutions but I believe it will be increasingly rare.
Whilst a large number of consultants in the UK working on building projects have adopted Autodesk Revit as their chosen authoring tool (other solutions are of course available!), many civil engineering projects have utilised Bentley’s software solutions (Bentley solutions also cover buildings as well). At some point these two different solutions will need to interface, either now or in the future. Equally many steelwork sub-contractors have chosen to adopt Tekla Structures. These varying solutions immediately create the need for interoperability.
Of course as an ARCHICAD user (or indeed other authoring software users for Nemetschek Vectorworks, Allplan or DDS-CAD for example) we need to interface with these solutions as well. But this is only looking at software exchange between authoring platforms. Other solutions are predominantly more interested in the data, take for example costing software such as Exactal CostX or Causeway BIM Measure. Then eventually models need to talk to all manner of client CAFM systems. This is only a small selection of the BIM functions possible and the available solutions on the market but you can begin to see how many connections need to work.
So there are two simple solutions to this problem as I see it – plugins between each solution or a common format. Plugins are ok but in the long term they aren’t really sustainable given the plethora of both existing and emerging software. So the industry will benefit with the increased use of common BIM exchange formats. We had DWG for 2D so its a case of having the same for model and data exchange. This of course is where standard open industry formats like IFC come into play. I’ll concentrate on IFC for this blog but BCF and COBie also fall into the category of open industry BIM formats.
So if we begin to understand the problem with a vast array of solutions out there, then we need to understand what benefit these formats will bring to us as individual companies. In order to do this we need to understand our outputs. These vary depending on discipline. As architects and ARCHICAD users I will focus on our view of the world when it comes to IFC.
Building Information Modelling (BIM) is essentially all about the ‘I’ part and this is what separates it from simply working in 3D. Lots of people think they do BIM but there are lots of outputs you can produce directly from a 3D model without even tackling the ‘I’ part. If your not tackling the information, then ask yourself are you really doing BIM? (thats not a criticism, everybody is at different stages of their journey and I ask myself this every day but be honest about where you are). So outputs from a model could include drawings, visualisations, animations and 3D printed models and these can all be produced without the information part. They are of course part of a step towards BIM but they can lack true ‘intelligence’ and yet still produce useful outputs without strictly being called BIM.
There are odd exceptions to this rule. Even a 3D model can be used to generate data and intelligence. A piece of software like Sefaira is a case in point. This uses a 3D model to provide feedback on the model for environmental design. The intelligence is applied to initial 3D design geometry outside of the authoring tool. This can then be used to influence the original authored design. So there is intelligence here but not directly through the authoring tool. Sefaira qualifies as BIM but the authored model itself could still essentially be just 3D.
So with a model that has no data you can create an IFC file which is purely about geometry – see my previous post for what you need to do to achieve this. It will inevitably contain some data (more of this another day) but for now we can think of this just as geometry. So why bother? Well if you follow what was set out in my last blog you can begin to share your model with others. As a minimum others can open this in one of the many free IFC viewers (see our interoperability page for a list of some of these) or better still in their own authoring tools or other compatible software. ArchiCAD users might say we should use BIMx (a model viewer) and yes this is a way of issuing the model but IFC can be used in tandem and presents other benefits. BIMx is currently an end result and has its place but IFC offers more opportunities for others to take advantage of the work you have generated.
BIM is also about collaboration so being able to exchange models with other like minded consultants for coordination is a leap forward from just modelling for your own needs. They can open your models in their own software and you or others can combine (or what is known as federate) these models into other software such as Autodesk Navisworks, Solibri Model Checker, VICO or Tekla BIMsight (to name just a few solutions on the market). These can offer the ability to carry out clash detection (checking everything fits). All of these solutions provide support for IFC import. Straightaway you are into the world of collaboration and you’re really on your ‘BIM’ journey.
Image: Key to modelling sharing between project participants and the ability to produce a single federated model is the ability for a variety of software solutions to all talk to each other.
Even if you don’t have anyone to collaborate with you can still look to take some benefit. For example, you could invest in software like Solibri Model Checker to check your model geometry against a set of rules (it can check data as well of course). This can automate processes to ensure your design meets certain criteria and check the integrity of your model. This ticks boxes when it comes to quality assurance and theoretically is an opportunity to reduce your insurance premiums.
Building information models
Beyond 3D models we begin to truly move into BIM. With BIM as opposed to just 3D, IFC really becomes increasingly powerful and really deliver what it was designed to do – exchange data. This data can be used by many parties, from consultants to contractors to clients depending on their need. I will talk more about the data that we can input/output from ARCHICAD in detail in subsequent posts. However, often what is overlooked is that the BIM part from an architect’s point of view is crudely split into 2.
First there is delivering BIM to produce the same outputs you had previously, but more efficiently. As an architect this would include outputs such as door schedules and window schedules. Secondly though you need to think beyond this and realise that the outputs grow because you need to consider all architectural elements not just those we traditionally have scheduled. This means information embedded into walls, ceilings, roofs and so on. Many people think architects are simply creating efficiency through BIM but for me the outputs begin to change as you collaborate more with others and they want to take data from all of the architectural building elements.
So looking at ‘part one’ of BIM you could produce this information in your own authoring tool, produce the output as a schedule (e.g. Excel or PDF for example) and then issue. Technically with ‘lonely BIM’ you don’t need to issue the model, it is merely the vehicle to deliver the outputs. Of course there is nothing to stop you issuing the model but some elements may not have data added. You will need to be clear what data others can use for their purposes. Much of this data can be created in ARCHICAD with ‘native’ ARCHICAD parameters (e.g. parameters for listing) so this is why many people don’t look at IFC. Within ARCHICAD – doors, windows, stairs and other objects contain this ‘native’ data.
Image: Native data in the form of ‘Parameters for listing’ for a Chair within Graphisoft ArchiCAD
Using IFC in an ARCHICAD ‘lonely BIM’ environment also allows you to interface with other IFC compatible software. For example, dRofus is a tool that can link to IFC models and create Room Data Sheets and FF&E Schedules along with other useful deliverables. Solutions like this begin to leverage the data that you have created and again add controls to ensure that the data created is correct.
With ‘part two’ your model has more data and the model very much becomes part of your deliverable and actually most of this ‘added’ data is only going to be in the model. You may choose to use the authoring tool to create schedules for checking purposes but this output may not necessarily be a contractual deliverable. Now with these ‘other’ elements requiring data, ARCHICAD tools such as the wall tool, slab tool, roof tool, beam tool, column tool, shell tool, morph tool don’t contain the same ‘native data’. They have some but not everything that is needed (again i’ll explain this in more depth another time). So here we begin to look at using IFC data.
Now we could continue to use ‘native data’ for ‘part one’ and use IFC data for ‘part two’ but this just adds more complexity. (Note: ‘native’ data can be exported in an IFC file but there are some additional things to consider with this route – i’ll cover this in another post). It also limits our ability to use all the tools and produce the required schedule output. Our solution is to add all our data into the IFC data fields. This creates consistency for all users and is also more straightforward in explaining to others our data outputs.
Image: The same data as the ‘native data’ but using IFC fields instead for a Chair in Graphisoft ARCHICAD (note: this is for illustrative purposes only – you wouldn’t do this straight match as some of these fields already exist in the IFC properties but it explains the point that any data can be created in IFC)
Image: Another way of looking at the IFC data for the chair in Graphisoft ARCHICAD
One of the advantages of using IFC data is where you choose to use an object (such as door, stair, window or other object) that does not have ‘native data’ in the form of ‘parameters for listing’. See my earlier post entitled “Sketchup to IFC (and COBie) via ARCHICAD“. This means we don’t have to worry about GDL (ARCHICAD’s object format) object quality. We are actually creating our own dataset and can apply this to any geometry.
For me as an ArchiCAD user, BIM and IFC go hand in hand. What it boils down to is “Why do BIM?” and “Why use IFC?” are essentially the same thing. If you don’t ‘get’ BIM first then you probably won’t ‘get’ IFC. BIM is about collaboration and data and IFC is the format to allow that collaboration and data sharing but most importantly being platform independent. This means you should be able to work with any other IFC compatible tool of which there are many.
I’ve alluded to some of the benefits of an IFC approach in this post. But you still may be asking why IFC if you are only a small company? Well its pretty simple, set your business up to grow. BIM should be on your roadmap even if you are small, and being small makes you more flexible. If you know what you’re aiming at then it is easier to get to where you want to be in the future. Think big and work back from there. Using IFC data instead of ‘native’ data is one way to think of creating an approach that is going to deliver other benefits in the future and provide your staff with a consistent approach from the outset. Setting up templates and approaches with IFC in mind really isn’t loads of extra work at the outset but it will be a lot more work trying to change (we all hate change!) and do this later. Once you hopefully get to a reasonable scale you can collaborate more and more and by the time you do, IFC model and data management as part of a wider approach to BIM will already be second nature.
Rob Jackson, Associate, Bond Bryan Architects