IFC in Autodesk: The Next Generation

MAREK SUCHOCKI: Welcome to this Autodesk University 2022 class on IFC and Autodesk, The Next Generation. My name is Marek Suchocki. I am a global business development executive working with the named accounts teams. And I'm joined by two excellent product colleagues, Angel Velez and Nigel Peters.

So we're obliged to show the safe harbor statement to ensure that some things that you see may not come to fruition, because we are always developing our products. But hopefully everything will be clear as to what is ready and what is not ready.

So what are you going to hear today? We're going to talk about buildingSMART, explain what that organization is, and how Autodesk has been involved in it. We'll discuss how Autodesk currently supports IFC, Industry Foundation Classes, in our products today. We will see some investments that we've been making in the Revit and other product in our roadmap. And finishing with an extensive overview of how we've provided IFC support within Civil 3D. And lastly, a brief summary of what you've heard and what you might be looking to do next.

So let's start looking at buildingSMART and what is an IFC. So firstly, some of you may not realize, but Autodesk set up what has become buildingSMART today. Back in 1994, Autodesk created what was called the Industry alliance for Interoperability. They invited some 20 other software companies to work on sharing information and geometry seamlessly between products.

A couple of years later, the community was expanded to inviting anyone who was willing to apply. And it became the International Alliance for Interoperability, looking to develop what were called Industry Foundation Classes, or IFCs. And the first one was released the year later. And version 2 in 1999, there's a plaque you can see where Autodesk was identified as a platinum partner of the International Alliance for Interoperability, or the IAIs as it was. And IFCs continue to be developed through the years.

So 2003 IFC 2x2 been released. And this was probably the first release that was viable as a thing that you could specify in projects to share information between different softwares.

Because international Alliance for interoperability was a bit of a mouthful, and also because the focus of the data model that was being developed was principally in vertical construction or buildings, IAI renamed itself as buildingSMART in 2005. And later that year, what is still probably the most commonly used data model or schema, IFC 2x3 was released. This was followed by IFC 4 in 2013.

A extension was developed by the infrastructure room, which you'll hear a bit more in 2018, called IFC 4.1, which was principally a alignment or a string line. And then this year we've had the release of IVC 4.3, of which you'll hear more about shortly.

So firstly, what is an IFC? I know some of you may be very familiar with it. But others may have heard of it, but not be clear on what an Industry Foundation Class might be. Well firstly, it's a data model. It's an object based data model for architecture engineering and construction data. It is a open file format specification. So it's not owned by any particular organization, but it is managed by buildingSMART, as well as buildingSMART's members.

For a valid IFC file, we need three components. The IFC schema itself, the IFC version, so I mentioned versions 2, 2x2, 2x3 just now. And what's also known as a model view definition, or MPD, which specifies a subset of the IFC schema that can be used for an exchange. And you'll hear more about that later.

IFC is a ASCII file format at its heart. So it is something that can be human readable. So it's a small extract of an IFC. And it is also an international standard. So [CLEARS THROAT] pardon me. ISO 16739.1 was released in 2018, and that's for IFC Forge, you may have heard about. And there's also a URL in there in the corner, if you're interested in learning more.

BuildingSMART itself is a international member organization that is composed of its management committee, standards technical executive, as well as committee executive, and certification group. But fundamentally, it functions as a group of technical rooms providing data models for certain industries subsets, looking to extend the IFC data model into new areas or [INAUDIBLE] coverage.

I'm very pleased to say that Autodesk is represented in a couple of the rooms. The technical room, my colleague Angel, who's on this session with me, and myself in the infrastructure room. Autodesk is one of nine strategic advisory council core funders and members of BuildingSMART International. And you can see the others that are represented there. And these groups provide significant funding, as well as guidance and direction for future investments and technical roadmap for buildingSMART that support those groups we saw earlier.

BuildingSMART is also composed of a number of international chapters. And these are the local working groups. And you can see the countries that are all regions that Autodesk is participative in, such as UK and Ireland, Canada, Australasia, Japan, and so forth.

We mentioned infrastructure room. And infrastructure, or the InfraRoom was established back in 2013. Because one of the shortcomings within the IFC data model was coverage of civil infrastructure. It's great for vertical construction of buildings, as I mentioned. But not so good, if you're sharing roads, rail, or utilities. So you can see the mission and scope for the infrastructure room and how it worked to provide this additional coverage for this technical domain of infrastructure.

And this infrastructure room is, again, composed of participants from many regions and organizations. I, myself, am part of this steering committee. And I'm the current chair of the project steering committee. And these projects have been working to address certain core elements of the infrastructure domain, such as the alignment, which we mentioned earlier.

It needed to be refined from the 4.1 release to accommodate additional requirements from roads and railways. Ports and waterways, tunnels, bridges were all focused on and common schema. So these would be elements like embankments, cuttings, utilities, and other items.

And that common schema also extended to rail. Rail was part of the infrastructure room. But was spun off into its own railway room. Because there was a huge stakeholder participation and sponsorship, especially from railway owners who were really keen to see rail have extensive coverage. Because they had a shortcoming in what they could specify and what they could receive in data handover. All this work has led to what's known as IFC 4.3 extensions. And there is an ongoing program for IFC 4.4, which includes tunnels, and ports, and waterways.

The organizations that have been engaged in the infrastructure extensions are international and looking at different use cases. Here is a core group that has been listed. There are many others, as well. So if is listening and says, why is our company not on there? It's purely to provide an indication of how extensive the participation and collaboration has been.

And from the rail side, I mentioned that there's been great sponsorship from rail owners. So you can see organizations like TrafikVerket from Sweden, Austrian Rail, Swiss Rail, SNCF in France, and China Rail BIM [INAUDIBLE] as well.

One of the things that the investments for IFC 4.3 has done is to focus on exchanges. And these need these modal view definitions that I mentioned earlier. So it's typically possible to reference things using an XYZ coordinate based approach. And this would be what you might see in a buildings exchange. But those of us who work in civil infrastructure, we often reference things from an alignment base. So x distance along a change of a road and an offset to the left or right of y point xyz meters or whatever.

So alignment based referencing is different to coordinate base referencing. And so one of the key extensions for IFC 4.3 has been able to has been the need to accommodate this approach to referencing. And interestingly, alignments is something that don't always have a meaning in many BIM softwares, because what is a string line in a modeling [INAUDIBLE]. So this is something that software companies have had to overcome.

And the final piece of work that's really on the way at the moment is to develop those core and model view definitions. And the ones that are listed there are the generic ones that are needed. And they're needed, not just as a way to provision standardized exchanges, but also to allow software certification to take place. And this certification, once those MVD are finalized, which is hopefully imminent, will commence in quarter three of 2022. Meaning the certified software should be available for use either late this year or early next year.

Interestingly, this work has also been done in collaboration with AASHTO, which is an American standards organization for highways and transportation. And they wish to include an IFC 4.3 bridge model view definition as a specification to US industry when either new bridges are constructed and designed , or when they've been inspected. So that we can have consistent data capture of the tens of thousands of bridge assets that exist in the US. And I'm sure the same approach would be taken up by many other infrastructure owners globally.

So with that, I'm going to hand over to my colleague Angel Velez, who will tell you more about how we support IFC in our products today.

ANGEL VELEZ: So we are concentrating on Revit and Civil 3D in this presentation. It is important to know that our IFC support and our future IFC roadmap isn't just restricted to these two products. Autodesk supports IFC throughout its product line for both desktop and cloud products, such as BIM 360 and the Autodesk Construction Cloud. It isn't just restricted to AC either. For example, a vendor has IFC 2x3 export support, which it achieves by sharing the Revit IFC engine. We'll talk more about how we share our IFC implementations later.

We also aren't just restricted to IFC 2x3, although it does still remain the most popular format. We provide IFC support in a handful of products, such as Revit and Navisworks and BIM 360 and are looking to expand the reach of IFC 4 and IFC 4.3 by our Autodesk translation framework, which is ATF, and our Open Design Alliance collaboration, ODA. And we'll also come back to those concepts later. When future versions of IFC arrive, such as IFC 4.4 and IFC 5, we'll also evaluate them. So that our customers always have the most up to date open interoperability access available built into our products.

So as we talk about how Autodesk supports IFC today and where our roadmap is taking us, it's important to have some guiding concepts in mind. To help us figure those out, we sent out surveys to our customers and asked, what are the most important issues you're facing in IFC today? The results that came back generally fell into three categories.

The first and highest ranked was request for consistency. Users need to have confidence that the data they produce and consume matches the source of truth within the context of the capabilities of IFC and the appropriate model view definition.

There's an important distinction, because we're not promising that our short or medium term goal is lost this roundtrip of all model annotation data. There's no IFC model definition that supports that, and likely never will be. The data must match what is supported by the MVPD, which reflects an agreed upon workflow. Without consistency, there's no trust in the data. Users are forced to find other ways to communicate their data.

As a close second, users want a good performance. These users generally found that the data being generated was acceptable, but that read and write operations were too slow. This is especially true for applications like Navisworks and BIM 360, which are intended to quickly display large amounts of external geometric and parametric data. For BIM modelers like Revit, performance is relative to expected usage. We expect, for example, that linking an IFC data for reference should used only to be faster, and more visually accurate, and doing a design transfer into Revit for the purpose of continued editing.

In addition, we expect that the act of creating native parametric objects would necessarily take extra time and may require some approximation. Performance of that consistency first, however, is meaningless. Lastly, people wanted the flexibility to modify how their data was generated and how it was interpreted. Revit IFC Export, for example, has a lot of controls that allow for user control over how their data is exported, but they are hard to discover and use.

We need to make our current controls discoverable and intuitive, and extend the options that allow for maximum sensible customization, we'll come back to specific ideas about how to achieve this in the next few slides.

As we mentioned before, consistency is the number one issue for our IFC users. Repeating what I said before, users need to have confidence that the data they produce and consume matches the source of truth that generated the data and has the capabilities for the required workflows. To show this, we participated in externally run certification processes that work against the specific schemas.

The majority of these are managed by buildingSMART, although we also participated in country specific certifications, such as the IFC 2x2 E-Plan check certification from Singapore, back in the early 2000's. And more recent certification programs are underway in Singapore again and Japan. We have participated in every building site certification process available. The reason we don't have any IP 4.1 certification shown is that none were ever available from buildingSMART.

So from here we'd like to take a few minutes to see where we intend to take IFC in the future. So this is concentrated on Revit, but isn't just Revit.

Once we identified the three areas of focus that we mentioned before, we're able to look at requests from several different sources, and group them into a cohesive plan moving forward. While this roadmap is Revit-centric, the products here affect almost every other Autodesk product that includes IFC, especially Navisworks, BIM 360, and Inventor, which currently share an IFC engine with Revit.

Note that this is a work in progress and that we intend to be agile in our delivery. So the specifics aren't unimportant particularly important here. Although, we'll cover some of the upcoming projects in the next couple of slides.

So while the vision map on the previous slide was primarily for internal use, we still wanted to share our vision for our upcoming IFC projects. If you're interested in following along at any time, you can visit the Revit Trello public roadmap page, which has a specific column for IFC improvements. And you can find that online just by searching for the Revit Trello public roadmap pages I just said. Each of our focus areas has at least one project on this page in the IFC column.

So for consistency, our current focus is on wrapping up IFC 4 certification, which we mentioned before, but that's not all. Other areas of improvement include federated export, which is the ability to export a host and all of its things as one IFC file. And to improve the consistency of IFC goods for improved change tracking, which is one of the prerequisites for the federated export.

We want to have improved consistency and performance around the creation of parameters as part of Link IFC, by hooking it to the cloud based parameter service, which has recently been released by Autodesk. So there, the idea would be that you wouldn't have a lot of IFC specific parameters, which are recreated by companies over and over again. Instead, you would use the one definition for these common properties.

And we also have a number of small enhancements that have been highly requested, such as better material parameter support. And continued improvements in the UX around mapping Revit categories to IFC entities, as a precursor to allowing us to export anything as anything. So again, that's the ability to take any Revit element. And regardless of how it's categorized in Revit , be able to map it to the IFC entity that makes sense for your particular workflow.

So to achieve our goals of having the best lives IFC support possible. We had to look at the components we were using for our IFC implementation throughout the company. One core component that needed modernization was our toolkit to read and write IFC files. So looking around, we found that we could achieve the best results by partnering with the Open Design Alliance.

Autodesk joined the Open Design Alliance in 2020. We'll adopt their IFC software development kit, beginning with integration with ODA into Revit, which has already been finalized and has been released as part of the Revit 2020 2.1 release. As before, by doing this, this immediately improves our Forge, Navis, and Inventor IFC support. As you can see from the slide though, we do intend to extend the usage to many more applications. And this will require another bit of technology this time internal to Autodesk.

So we want to share our IFC implementations as much as possible, not just the ODA IFC toolkit. To achieve this end, we plan to integrate IFC support into ATF, which is the Autodesk Translation Framework, which is a technology that is already used in products, like Inventor and Revit, to provide support for external 3D applications, such as Rhino and SketchUp.

Extending this framework to support the BIM concepts needed to do IFC correctly allows for us to use the Autodesk translation framework in conjunction with ODA to have a shared IFC experience that can be extended to new products, where improvements in one area helps everyone. A single reasonable IFC solution that is decoupled from the product release schedule also allows development teams to focus on product specific integrations and customers to trust the implementation across Autodesk solutions.

At Autodesk, we've also had a long commitment to making our IFC implementation as open as possible. We have originally open sourced our Revit IFC implementation in September of 2011, 11 years ago as of earlier this month. Originally on SourceForge, we moved to GitHub for the Revit 2019 release and are there today.

Originally, we posted updates there on the Autodesk app store. But as of the Revit 2022 and 2023 releases, we're instead posting updates to the Autodesk desktop app. So you can always be up to date with the latest IFC improvements without having to go anywhere to manually download, based on update messages that you need to track.

This open source approach has two distinct benefits. First, it creates a forum to discuss specific issues that is open to the public and allows anyone to fork the main branch to make changes to the IFC code improvements that are specific to their organization. Or allows them to fix a particular bug that is relevant to their ongoing projects without having to wait for Autodesk to do so.

Second, it allows us to make updates to asynchronously from Revit updates. This allows us to be able to quickly respond if a serious issue is sound, or if a major update is needed, and for example, a new version of it is released or certified. These updates don't just benefit Revit. As we've said before, Navisworks can use them, too, as well as BIM 360. As we look to synchronize the IFC solution across Autodesk products, other products will potentially benefit in similar ways.

An example of how this asynchronous update has come in handy is in Revit's IFC 4.3 import support. As Civil 3D continues its path to creating valid IFC 4.3 based content, Revit and Navisworks has been able to keep up with the changes by updating the open source implementation, based on the Civil 3D sample data. It isn't always possible to backport all changes to previous Revit versions. But in general, we've been able to release dozens of bug fixes and quality of life improvements, often after the last major point releases have already been released.

And now I'll pass it over to Nigel, where he can discuss the specifics around IFC 4.3 and Civil 3D.

NIGEL PETERS: Four months ago, buildingSMART publishes the first official schema for IFC 4x3. And that is really focused the 4x3 release on civil engineering. So it makes total sense that we need to support it inside Civil 3D. And we started developing a plug-in about 12 months ago, when we were doing some beta testing and validation testing with buildingSMART. And then at the beginning of this year, we put that plug-in into alpha with customers. And we've been working closely with major customers for the last eight months on making sure that this plug-in is fit for purpose.

The new plug-in has been released, it supports IFC workflows in Civil 3D 2022. And the plug-in supports multiple IP formats. So on import, we can import some geometry from IFC 2x versions. But we can support reference views from IFC 4, 4x1, 4x2, and 4x3. And for export, because this is civil engineering and IFC for civil engineering really only started being around with reference views in IFC 4, we support exporting in both IFC reference views version 4 and IP 4x3. We don't support the deprecated versions for export of either the 4x1 or 4x2, because buildingSMART have now deprecated them with the release of 4x3.

The plug-in support objects to IFC Entity and type mapping. So again you can specify what objects, what your blocks, what your solids, what your civil draw styles ends up as when they're exported out to the IFC file in a fairly flexible predefined way. We also support metadata mapping. So any of the metadata that we're exporting you can define what type of IFC properties is and what property name is used on the export.

And the big difference between IFC 4x, the [INAUDIBLE] 4x version, is this concept of a sectional swept solid. This is how a corridor is modeled, but lots of software does not support sectional swept solids. So IFC has allowed us to have a fallback BREP geometry. So if the tool you're using supports IFC for reference views and also support fallback geometry, you do not need to worry. You can still import that data into that software very easily.

The IFC plugin for delivery day IFC is about geometry. But I think one of the big problems with civil engineering is the large corporate systems we use. So our plug-in supports and creates a local reference datum, and support the use of coordinate systems, as well. But all the data is based around that local datum, and transform down to it on export, which means that you don't get any of the distortion that the old earlier implementations have in civil engineering.

On the Civil 3D side, we support a vast list of objects natively coming out of the Civil 3D drawing. There's no exploding. There's no converting to AutoCAD entities. They just come out naturally. So we support COGO points and COGO point groups, feature lines, surfaces, alignments, corridors, bridges, pressure and gravity pipe networks, as well as AutoCAD solid polylines and blocks.

Corridors of the old one, they actually get supported in free as a corridor object in IFC as a roadway or a railway object in IFC. But they also get exported. Every point code is exported as a feature line, every link code as a lofted surface, and every shape code as a section or solid. And note, you do not need to create the corridor solid for this workflow to work. But if you do have them, we will take the metadata off the corridor solids, and attach it to the relevant shapes, whether we are exporting. It's a very flexible system.

But IFC is about 3D models. And we're really focusing on 3D. So things like 2D CAD entities, lines, arcs, circles, we're not exporting them. Text, and text tables, and labels, again, they're not required for a 3D model.

And again paper space and cross-sections, well, you're better off using a PDF for a cross-section or a profile view. That's what they're designed for, 2D drawings. And assembly definitions, the tools that we use to define the corridor, again, they're not exported. Just the pure 3D solved model.

And again, IFC is not designed for design to design workflows. There are some designed to augment a design. There are designs for quantity takeoff and construction workflows. But it is not designed for design to design models. Any parametric or calculated geometry is exported as a solved 3D solid. For example, a pipe chamber, or a pipe itself, that's exported a solved geometry. And again things like corridors, they're exported as solved geometry.

Alignments and profiles are broken down into individual curves and tangents. So you lose the curve groups, the spiral curve spiral groups. They get split into a spiral, curve, and spiral. Design parameters and connections are not handled by ISPs. So don't expect offset alignments to be handled. Don't expect targeting on corridors.

And I really need to emphasize this. A corridor defined by assemblies is exported as a collection of sole cross-sections, swept solids, lofty surfaces, and feature lines. If you then, in your downstream software, move the alignment, do not expect a correctly recalculated corridor. Corridor objects might or might not move, depending on the implementation, but they'll be miscalculated. They'll just be relocated and not recalculated.

And again, none of the object the targeting of that corridor, the sub-assemblies, the parameters that you've used are exported. The values of them are, and they're attached to the objects of metadata. But the actual physical links just do not get exported. Art has been pushed as-- it is a publishing environment. It is a publishing tool.

So here is a few examples of a Civil 3D model that I had. All I have done here is open the drawing in Civil 3D. And I've exported it, and produced a few RC files. There are several of these. And here I've got-- the model had AutoCAD solids representing the dry utilities, and the OCS electrification poles, and the signal. It had water solids for the sleepers. The rails you're seeing there are part of the corridor. They're are baseline feature from a shape code.

And again, here is a similar model. I've just showed more data. Again, you can see the track bed. That was a corridor section solid. Below that, you can see some pipe networks. Again, pipe networks and manholes exported, as you would expect.

And finally, a bit more of the detail. Again, the 3D the surfaces are shown here. There's a couple of things on the Civil 3D side I bought in from Revit, so like the little staircase on the platform. The poles came in as blocks from Inventor into the full 3D model, all exports with their metadata, correctly mapped to sensible things, or not using the mapping rules inside the IFC hierarchy.

IFC is not just about geometry. In fact, for some companies, they only really care about the metadata, and some workflows is metadata. So we attach as much metadata to every single object at the relevant level in the IFC tree as possible. So we extract the colors, the materials.

We create a fixed GUID. So that when you re-export objects, you can do comparisons based on what objects have changed. All property set data is exported. All user defined parameters are exported. Byte structure and fitting data, part data is exported, as well as a whole host of generic object properties using the standard .NET API to fetch them off the objects. So even custom objects, or third party objects inside your drawings will extract some metadata and attach them to it.

On importing, all objects have all properties that are associated with it in the file attached to them as property set data. And again, we have the IFC GUID, and we store the GUID. So you can import, and re-export, and see just the changes with the same GUID. So you can do downstream workflows, where you're just processing the IFC inside Civil 3D.

So Angel spoke briefly about Revit. Revit 2023 with the IFC-- Revit for IFC update 1, that was released earlier this year, will import as direct shapes inside Revit, fill 3D surfaces, bridge parts, that would pier, deck, et cetera, abutments. Gravity and pressure point corridors, that's the cross-sectional shapes of the corridor. AutoCAD solids and blocks.

And again, the picture on the right hand side is a site design. And it's not a very clear picture. I apologize. But it's a site layout with some pipe networks consisting of gas pipes, gravity pipes, and waste pipes, and pressurized water supply pipes. All the objects when imported into Revit get all the metadata that we exported. That's a metadata rich solution.

So here is the station I showed earlier imported into Revit. And again, I've selected one of the IFC poles. It's got all the metadata attached, because I did not filter out any of the metadata when I created the file.

But as you can see here, you've got the corridor section shapes. You've got the sleepers. You've got the platform. You've got the staircase geometry that was originally imported into Revit-- into Civil 3D from a Revit file. You've got the underground utilities. An extremely nice, powerful, milimeter perfect workflow between Civil 3D and Revit.

So can we import IFC using the tool into Civil 3D? So above is a bridge that I exported from Civil 3D. And I'm showing it in the ODA viewer. Below, the only thing I've changed in the viewer above is I turned the surface off, because it cluttered the drawing. Below is the bridge that I imported the same model into Civil 3D.

The alignments in this model came in as alignment, feature lines, surfaces, sites, COGO points, and point groups, and polylines all came in as editable, reusable objects inside Civil 3D. But all other objects came in as AutoCAD meshes or AutoCAD solids. So here you've got a Civil 3D surface that you can see that all the bridge parts came in as solved Civil 3D AutoCAD solids. And again, [INAUDIBLE] data is attached every single item containing the metadata that was saved in the IFC file.

And with that, I'm going to hand up over to Marek to finish off the talk and give us a summary.

MAREK SUCHOCKI: Thank you Nigel and Angel for those inspiring insights into what we've been doing around Revit, Civil 3D, and other solutions. So to conclude our presentation a brief summary and reflection on what's next.

So what can you benefit from now? Maintaining our subtle Star Trek theme, you can boldly go on using IFC seen your projects and for handover. Why? Well, because IFC 4.3 has been released by buildingSMART. AND it's due to become an ISO standard update to 16739 in 2023. So it's something that can be contractually certified by owners or project teams.

BuildingSMART has not rested on its laurels. It is continuing to extend IFC for infrastructure support with projects for tunnel and the new marine extension, as mentioned earlier as 4.4. And as well as significant other investments, both the infrastructure and building space, such as the buildingSMART data dictionary, information delivery specifications. And what's been branded as IFC 5, but it actually might be a new form of exchange definition for IFC. But watch this space from buildingSMART.

I mentioned that once IFC 4.3 becomes a approved ISO standard, then it's actually ready for public and private sector owners to start specifying it in their contracts. They will be able to know that they're getting a consistent data handover or consistent exchanges between the softwares. And hopefully, we've illustrated that it's already very robust, at least between the tools that we have with Autodesk.

And those Autodesk solutions are ready to meet those new requirements already. We were pretty confident on that. As we've shown, Revit has an enhanced support for IFC, including import of IFC 4.3 entities. The last image from Nigel really illustrated the comprehensive nature that can be achieved.

The Civil 3D IFC 4.3 plug-in is just now available. Please go to manage.autodesk.com to download it. We do encourage you to test it. And of course, provide us feedback on usability. And of course, Angel mentioned earlier, all the pre-existing support for IFC that remains available in our solutions.

We are awaiting for buildingSMART to make IFC 4.3 certification available. And we will naturally look to submit our solutions for that process. But that's outside of our control at the moment. Hopefully, it will be ready later this year. And those softwares will be ready in time for that ISO standard approval.

I'd just like to finish by reiterating what Angel showed you earlier. We've got a lot of investment that's gone on to provide extended support for Revit and Civil 3D, as you've seen. But the Autodesk Translation Framework investment the ATF, once that is working effectively with IFC, we hope to be able to provide consistent and reliable IFC support across a range of our solutions that all will talk to this translation framework.

So it's only going to get better, we hope and we expect. So please do continue to track what we do. And please do try using IFC and particularly IFC 4.3 in your projects moving forward, to improve the interoperability that's desperately needed in our projects and in data handover to asset operations. Thank you for paying attention.