BIM me up, Scotty - Interoperability and openBIM with Revit and beyond

LEJLA SECERBEGOVIC: Hi, and welcome to this Autodesk University session about openBIM. My name is Lejla Secerbegovic and I work as a BIM specialist at Autodesk in Germany. I was trained as an architect and I also worked more than 10 years in the industry before joining Autodesk. So I know from my own professional experience that the data exchange and the interoperability can indeed be challenging. But this is also the reason why I made this one of my main topics. And I also blog, tweet, and also record YouTube videos around Revit and IFC, so feel free to follow me on social media.

Today we'll first have a closer look at the role of interoperability here at Autodesk and the way it has developed over years. We will also discuss what openBIM actually is and which roles IFC plays in the openBIM workflows. I also give you a brief overview of the most popular IFC viewers and also mention which Autodesk software you can use for viewing IFC.

The main part of the session is definitely around Revit and IFC, where we will have a closer look at how you can use IFC files you receive from others in Revit, and what are the main things to consider when exporting an IFC from Revit. And last but not least, I will also share some interesting links and resources with you, so make sure you stick until the end.

Now let's start with a brief introduction. When it comes to the interoperability there is one organization which everyone knows, the buildingSMART. The buildingSMART is an independent organization developing open standards for the BIM data exchange, like IFC or BCF.

There is a common misconception that software vendors are not very interested in the openBIM workflows. However, these very software vendors, among them also Autodesk, founded the International Alliance for the Interoperability back in 1996, with a goal to develop a common standard for the data exchange. The Alliance was later renamed to buildingSMART we all know today.

In 2011 Autodesk published Revit IFC as open source to give developers the possibility to adapt Revit IFC for very specific needs. Interoperability between AC and design and manufacturing products has always been a challenge due to very different requirements, and one attempt to make this easier was adding the IFC support for Inventor in 2016.

In 2018 Autodesk published the first Revit IFC manual where you can find many tips on how to export high quality IFC files from Revit. Last year we did not only gain the IFC4 certification, but also joined the Open Design Alliance in order to collaborate on further IFC improvements. Also, Autodesk joined the buildingSMART Strategic Advisory Council, which is the core part of the organization and invested in working on interoperability topics.

This year, the main focus of our development teams was getting the IFC4 MEP Export certification, which is almost accomplished and will probably be in place when you watch this session. Also, we are working on the implementation of the ODA toolkit, which will in the first step make it easier for Revit to handle large IFC models. But there are also a lot of other improvements planned, so stay tuned.

Last but not least, this September we have released a new and completely revised Revit IFC manual, which will also be updated more regularly to keep on track with the latest developments.

Now, let's have, a look at the openBIM, the definition itself. According to buildingSMART, it is a collaborative process meant for the entire lifecycle of buildings and assets, and enables data exchange between BIM software. This can happen using different standards, such as IFC, BCF COBie, and so on. In this session, we will focus on IFC.

IFC, or the Industry Foundation Classes are the foundation of openBIM and the main standard developed by buildingSMART. It is important to understand that IFC is the semantic schema built, as its name already says, on classes, which define all objects or entities which exist in the standard. This definition does not only include the name, but similar to the Revit categories, also the relationships to other classes, the standard properties, and even the way the geometry needs to be described. But what's even more important, because it often leads to misunderstandings, is to understand what IFC is not.

IFC is not a file format. Let that sink in before I explain what I mean by that. We mentioned before that IFC is actually a schema, but this is an abstract concept for the most of us, and I like comparing it to a language for describing the BIM data.

The IFC data can be saved in different formats, and the most common one is using the extension, IFC. However, this is not a specific file format, but actually a text file based on the step format, and this also means that you can open your IFC file in any text editor and see its content in plain text, something you cannot do with a Revit file, for example.

Now, let's have a closer look at IFC. And don't worry, we won't get too deep into the theory. We will only cover the basics relevant for us BIM users. When talking about IFC, it is important to be aware of the current versions that are being used. IFC2x3 was the standard for a long time, but it is being slowly replaced by IFC4, which is the most recent development, and offers several improvements. Among these are a better handling of large models, and some new classes.

The buildingSMART is already working on new functionalities for the infrastructure in IFC4, which will be released as point updates for IFC4. In IFC5 then, we can expect further improvements for infrastructure, but also for other industries. I like using this image created by Thomas Liebich, often called the godfather of IFC and one of the best known IFC experts, because it shows that we still have a long way to go with IFC to be able to describe the full complexity of the BIM projects. IFC is a great concept, but just be aware of the fact that it indeed has certain limitations, and as long as you respect these IFC works great and does its job.

Next to the IFC version we always need a Model View Definition, which is defining a subset of the IFC schema for a specific use case. It is not possible to export an IFC file without an MVD. We could compare it to a 3D view in Revit, where all the elements, analytical models, and the calculations are displayed at the same time. In order to make this data usable and readable, you need to filter it according to its dedicated use case. In IFC, this happens through the Model View Definition.

In most cases, you will be either using the IFC2x3 Coordination View 2.0, or the IFC4 Reference View. Both are meant for sharing data in coordination workflows. IFCs created with these Model View Definitions are meant for viewing in an IFC viewer, or for referencing in other BIM software.

Beginning with IFC4, the buildingSMART has also started working on a dedicated Design Transfer View, which will be offering better results when imported or opened in a BIM Editor, something that is limited with other MVDs and can lead to a data loss. One thing to keep in mind, however, is that the scope of an IFC4 reference view is slightly more specialized, and therefor smaller, than the IFC2x3 Coordination View, which is also why IFC2x3 is still often used and is also recommended if you really need to open or import an IFC file in Revit .

It is also very easy to see which IFC version and MVD has been used in a file you received from someone else. Just open it in a text editor and check the header for the view definition and the file schema.

On the buildingSMART website you can find a complete overview of all the MVDs defined and maintained by buildingSMART. Notice that there are special MVDs, for example for the energy or structural analysis, however many of these are still under development. Apart from these, authorities or clients can also define their own MVDs if they have very specific requirements. If nothing else is specified in your project requirements, always use either IFC2x3 in Coordination View 2.0, or the IFC4 Reference View.

Most frustration in openBIM workflows comes from wrong expectations. It is important to be aware that the recommended workflow today means that the designer delivers an IFC file for a coordination, like reference, or other [? cross ?] design processes. However, not for editing purposes. If something really needs to be changed in the model, this needs to be done by the designer himself, who will then export an updated IFC file.

Editing IFC file is not only problematic due to the current technical limitations, but also due to the responsibility issues. In most projects a designer is responsible for what he delivers and this deliverable must not be changed by anyone else. In certain cases, for example, if the designer changes between the phases, and another designer needs to continue the project in another software, an IFC can be opened or imported into a BIM editing software.

However, we need to be aware that this will cause a certain data loss and is not recommended by buildingSMART. Even in the description of the IFC4 Design Transfer View, which will, as already mentioned, make this workflow a little bit easier, it is clearly stated that this is not a round-trip transfer, but a higher fidelity one-way transfer for data and responsibility.

For Revit users, it is important to keep in mind that the Revit IFC extension is updated independently from Revit. For this reason, you need to regularly check and update it through the Autodesk app store, and soon this will also be possible through the Autodesk desktop app, or through the Autodesk account, like with all the other updates for the Autodesk products.

The complete source code can be accessed through GitHub, which is relevant for developers among you. On GitHub you can also find the user forums, which are monitored by the Autodesk IFC development teams, and also regularly visited by other IFC experts, so I encourage you to visit it as well.

Autodesk is also offering several interoperability tools which can be very useful, not only for the openBIM projects. With the Model Checker you can check the quality of the model before exporting the IFC file, like for example, checking whether a certain property contains valid values.

You can also check the general health of the Revit model, including the number or sizes of loaded families, duplicated elements, or other things which can influence the overall quality of the model. The Classification Manager and the COBie extension let you classify the model for many different use cases, and also prepare it for the IFC Export. We'll have a closer look at the Classification Manager in the Revit section a little bit later.

The most essential tool when working with IFC files is an IFC viewer and there are a lot of free IFC viewers out there. The viewers basically read your IFC file and display it in a visual way. I personally recommend having at least two viewers to be able to compare the results when something looks wrong. I deal with many BIM professionals and from my experience these three viewers are the most widely used ones.

The Open IFC Viewer, by the Open Design Alliance, is the newest one in the list and is very promising because of its speed and the quick implementation of the newest IFC features. The BIMvision viewer is great when working with classification systems and it has an integrated support for displaying and filtering the classifications. The BIMcollab ZOOM is also widely used and I find it also very intuitive and fast.

The Autodesk Navisworks can read more than 50 file formats, including IFC. It might not be the fastest IFC viewer, but it offers extended BIM management features as well. Navisworks uses the Revit IFC engine by default and therefore requires updating the Revit IFC plugin, no matter if you have Revit installed on the machine or not.

It is important to keep in mind that Navisworks offers two conversion methods for IFC files. The modern one is also the standard setting and uses Revit IFC, as mentioned. The legacy setting uses the older Navisworks engine and it might be still faster with large IFC files at the moment. However, you should keep in mind that it is an older development and may not have the same support for new IFC features as the modern method.

Of course, you can also view IFC files with Autodesk Docs and also with the Autodesk Viewer which are based on the same cloud technology. On both platforms you have the full access to the model structure as well as the properties in IFC. Autodesk Docs is included in the AEC Collection, just like Navisworks, and the Autodesk Viewer is even completely free and offers sharing and commenting features as well.

Now let's talk about Revit, which is our core BIM software in the building industry and which offers a really good IFC support, if used correctly. First of all, let's have a look at the different ways you can use IFC files you receive from others in Revit. The intended use for a coordination workflow is the Link IFC, which references the IFC inside of your Revit project, and which is also currently our main development focus. You can view the content of the IFC file and use it as a reference for your own design, however you cannot edit it. If you need a change you need to submit a request to the designer, who will then send you an updated IFC file.

The second way is to open it in IFC in Revit, which actually imports all the content and converts it to native Revit geometry. And as mentioned already, this is not the recommended workflow and can lead to data loss. Therefore it should be used with caution.

The quality of the IFC file in Revit depends in the first line on the quality of the export itself. However, there are a couple of things you can tune on the Revit side as well. If you check the IFC options in the Open dialog you will notice that next to the mapping table which maps the Revit categories and IFC classes, and should cover the most common use cases out of the box, you can also set a template to be used when linking or opening IFC files. It is recommended to select a minimal template here, as big templates with lots of pre-loaded families, views, and sheets can blow up the IFC file without adding any value.

As mentioned already, the Export settings are essential for the quality of an IFC file. Therefore let's have a look at the most important settings when exporting from Revit. In the Export dialog you can find a similar mapping table as we saw in the Open dialogue. Here you are just mapping the other way around.

The list of the Revit categories is pulled from the project itself and can be misleading because it also lists all subcategories. However, you cannot map subcategories to other IFC classes in most cases, just as you are not able to map the IFC type on this level. Keep in mind that these are the global settings and valid for the whole project. Therefore, it does not really make sense to assign an IFC type which is the equivalent to the Revit type on this level. We can refine these settings later.

Notice that you can always adapt the table to your needs and exclude certain categories by inserting Not Exported in the IFC class field. You can save the custom mapping, and you can always reset the hard-coded settings by deleting the default file, shown in the header, from your hard drive and then simply regenerating it by clicking Standard.

This is also useful if you use Revit in different languages and the mapping table suddenly displays the categories in two or more languages. Simply delete the current text file shown in the header and hit Standard, which will reset the hard-coded settings.

To better understand the complexity around mapping let's have a look at a very simple example. Slab, as it is defined in Revit, can either be an IfcSlab or IfcCovering in IFC. And if we have a look at the IFC types it gets even more complicated. And this makes it clear why it is so hard to map on a global level and why we need to refine the mapping on the element level.

On element level you can easily override the global settings we chose before using the property IfcExportAs, which can be added either as an instance or a type parameter. Here you can enter the IFC class, followed by the type and separated by a dot. And you could also use Don't Export to exclude a particular element from the export. In this case, for example, we model the floor covering as a separate slab because we don't have an appropriate category in Revit. In IFC, however, we do have an IFC class for covering and even a type for flooring, so we can override it for export.

Now probably you're wondering how should you find out what the appropriate class and type are. To answer this, let's have a brief look into the buildingSMART documentation and how you can browse it to find this information.

If you go to the alphabetical listing you can select between the different languages on the left side. Note that this is not available in the 2x3 documentation, so you should make sure you are using IFC4 documentation. If we now have a look at the covering you can see the name of IFC class at the very top. The best is to copy and paste it in Revit in order to avoid any typing mistakes.

If you scroll further down you can find the predefined types, which brings you to the list of all the types available in the schema, including the descriptions. Copy and paste this part to Revit as well, after the class and separated by a dot.

Another way to populate the IFC export as parameter a lot easier is to use the IFC classification manager included in the Autodesk Interoperability Tools I mentioned at the beginning. This tool comes with a predefined classification file for IFC and even creates the IfcExportAs parameter as a type parameter for you, if it is not already existing in the project. You can select multiple elements and populate its value with one click.

Another handy feature is that it automatically displays only the IFC classes valid for the selected elements. For example, in this case, only the classes suitable for walls. In the past, we used to have many restrictions around which Revit categories could be mapped to which IFC classes, especially around the system families. These are now being slowly lifted and, for example, you can export now a Revit Wall as IfcRailing.

However, keep in mind that the wall in Revit has other properties than a railing and some of the properties defined in the IFC schema for the IFC railing might be missing. Basically, you are disguising a wall to make it look like a railing and, depending on the combination of the Revit category and an IFC class, this will work more or less good, and therefore it is recommended to always use the correct Revit categories from the beginning if possible.

Besides mapping there are a lot of other settings available in the Revit IFC Export dialogue. The dialogue itself also shows you the Revit IFC version and you should always make sure to use the latest version available. There are many pre-defined setups you can choose from when exporting from Revit, and they are definitely a good starting point. However, you can also access the detail settings by choosing Modify setup.

Here it is important to select the In-Session Setup on the left, or to duplicate one of the predefined setups before making any changes. The setups in the brackets are locked and cannot be edited. The setups are saved with the project and you can also import the setups provided by others or export your own setups to be used on other projects. This option is often overlooked, so I just wanted to make sure you are aware of it.

As you can see, there are many tabs with options provided in this dialog, but I would like to focus on the property sets where you can define the information which will be attached to your elements. All the options available are documented in the Revit help and also in the Revit IFC Manual, which you can check for further reference.

When talking about the property sets it is important to understand the concept of the IFC Common property sets, which is the only one option activated by default in this tab. In general, we can export every property from Revit, but you should try to follow these rules and always use the Common IFC properties when available. These are defined in the IFC schema and can be seen as the universal language for IFC because they are always the same, no matter where the IFC comes from.

The recipient applications can therefore easily find and access this information without the need of further mapping. Basically they serve as an ID for your elements and make sure these are identified correctly. Only if there is no Common property available you should go ahead and create your own property sets, which are also attached to the elements and contain additional information.

So, what are the Common property sets? Let's have a look again at the IFC documentation. If we scroll a little bit further you can find the defined property sets. For example, the Pset_WallCommon, which defines the essential and standardized information all walls should have. Every IFC class has a similar definition and its own property sets. This also shows why it is important to use the correct categories in Revit from the beginning, and also to map these to the IFC classes as intended. Walls, doors, or furniture all have completely different properties in Revit, as well as in IFC.

Due to the many properties in the IFC schema, however, some of which are rarely used in many of the projects, not all of these Common properties are automatically included in the built-in Revit properties. For example, if we have a look at the Pset_WallCommon, you can notice that the green properties on the top are part of the Revit database and will be mapped automatically. The properties at the bottom in blue, however, are the properties which don't exist in Revit by default. In this case, you can go ahead and create these properties in Revit, using the same name and data type as found in the IFC schema and Revit will export and add them to the Pset_WallCommon automatically.

Let's have a detailed look at this. In the first example, you can see the result of the standard export with the Common property sets enabled. Only the properties already existing in Revit are exported. If we go ahead and add the missing parameters, either on instance or type level, these will be automatically added to the Pset_WallCommon. However, sometimes this is not desired, especially if you are not using the English version of Revit. Terms like "Combustible" or "Compartmentation" might not be the terms you want to use in your project.

Therefore let's have a look at another way we can accomplish this. In the Export settings you will also find an option to add a parameter mapping table. By using the parameter mapping table you can map any Revit property to a Common IFC property by using a single text file.

Again, it is only important that your property has the same data type, as you are not able to map a text to a number, for example. The text file is stored outside of the Revit project and can therefore be easily shared with other teams or reused on other projects. By following these guidelines you can make sure that your IFC files exported from Revit have a good overall quality and can easily be used by others.

As mentioned, not all of the properties relevant for a BIM project are defined in the IFC schema and you will often need to define your own parameter sets. This can be accomplished in two different ways and, as you might have guessed, both of these options are found on the property sets tab of the export dialog.

Using schedules is a very comfortable and easy approach and it allows you to simply combine the desired properties into a schedule, which will then be added to an own property set upon export. It usually makes sense to include either IFC, Pset, or Common in the title of these schedules to avoid all your schedules being exported as property sets through IFC.

The second way to add your own property sets is by using a mapping file similar to the Common IFC property mapping we saw before. This is a lot more flexible than the schedules because it allows you to store these settings independently from the Revit project and share it more easily in the team. You will find a template with instructions included in the IFC exporter, which you can use as a reference, but the syntax is actually very simple.

The first line always starts with the word PropertySet followed by the name of the property set and either I or T for "instance" or "type" parameter. So in new versions the setting does not make much of a difference, as the IFC export automatically searches for the parameters with the specified name, no matter if they are set as instance or type.

Last but not least in this line you need to specify the IFC class this property set is applied to. You can, of course, add multiple classes and separate them with a comma, or even use IfcBuildingElement to apply them to all the classes defined in the building. Below this line you add your parameters in separate lines and, of course, you can also define more property sets in the same text file. Just start a new section with the same syntax.

As mentioned at the beginning, we have recently published a completely new version of the Revit IFC Manual, where you can find all the topics we have discussed here today in a more detailed way. There are also some other interesting resources I would like to share with you. As mentioned I already created a couple of short videos on some of the basic concepts around Revit and IFC and I'm currently also working on some new ones. So you might want to check out my YouTube channel.

Also, you should absolutely check out the BIM Interoperability Tools I already mentioned. On the website you cannot only download them, but also access the full documentation and also a dedicated YouTube channel with detailed demos.

Another very interesting resource is the buildingSMART International Podcast, which features regular talks with industry leaders. If you are more into reading, there is a great book by Mark Baldwin, a Swiss BIM expert, called The BIM Manager, which discusses many important topics in a very clear and practical way, including general openBIM workflows.

Last but not least, I'm also learning a lot from others, and I would like to share some of the blogs I regularly read and appreciate.

Thanks for your time. I really hope you learned something new today, and don't hesitate to keep in touch through LinkedIn, YouTube or Twitter. Have a great Autodesk University.