I was fortunate to be able to attend BuildingSMART’s International Standards Summit in Montreal a few weeks ago in October. As an engineer who formerly lived in the design world in the US, I would evaluate which conferences are suited towards a specific objective to give me a competitive edge to win the next big project. However, this conference was different. It was about learning and providing input towards the guidance and development of an open data standard.

BuildingSMART’s worldwide supporters of open data standards, such as IFC, shows much promise in the future. This conference highlighted an amazing amount of progress made in the last few years with proven use cases in many industries. Not only was this conference a testament to the accolades of what other industries are doing with IFC, it was also a fantastic opportunity to listen to and provide a voice on a variety of issues. The active participants on the workshops only serve to make the movement for openBIM and open data standards better. The opinions that drive priorities, how open and understanding everyone was, and how willing everyone was to share their vision of the future really made a lasting impression on me. We were no longer owners, consultants, contractors, vendors. We were members of a community working together toward advancing our industry. On the transportation front, I wanted to find out how IFC is progressing as an open standard format, where is it required as a deliverable, and how are they using it today in the real world (not a pilot project, not in theory or as a thesis paper, but in practice).

I was surprised to find some of the answers in the first few hours of the opening session. In short, IFC is in continuous development and is mostly used in the vertical industry. Use in the horizontal market dwarfs in comparison, but it is steadily growing.

New Skillsets Required

It is required by some agencies around the world, but for what exactly? Some use IFC because it’s an easy format to input data and attribution towards model geometry. At times, there is a lot of effort being expended on this data attribution. In the road design world, there are less and less drafters coming into the industry. More drafters are retiring or leaving the profession as well. This puts a lot of strain on the designer to do detailed design, modeling, and drafting alone. Imagine if a significant amount of data attribution is also required. I think this could potentially make way for a new(ish) profession within our industry.

Currently, data attribution on 3D projects is mostly being handled by the designer. As agency requirements grow, the effort required to add this data through the asset lifecycle will grow as well. Sometimes technology can aid in this effort through automation and optimizations of workflows. It may also require the development of a new skill that can come from the designer or someone else entirely.

As expected, most of the people I happened to talk to were in the vertical space. Some were BIM consultants, some contractors, and some designers. I recall a conversation with a designer who now works for a contractor. I had asked her, “How do you use IFC today?”

She responded, “We don’t. We used to. Mostly for coordination and some kind of uniformity between deliverables.”

“Then what do you use now?”

“The original authoring application,” she responded. “IFC was great for coordination until we really learned how to consume the data directly. We have a lot more flexibility to make changes if needed and pull design intent”. Design intent describes the relationship between design objects so that when one object changes, propagations occur automatically elsewhere.

I‘m likely paraphrasing parts of the conversation, but I keep hearing that IFC can carry (or will soon carry) design intent. While this may one day be a reality, it is certainly not one any time soon. Other misconceptions I often hear is that roundtripping or that an IFC file carries security so one may “sign and seal” the file.

Messaging

During the opening plenary, Marek Suchocki of Autodesk spoke about the history of openBIM, how Autodesk supports it, and most importantly, some of the messaging challenges that we face regarding IFC. I found myself in the peculiar situation of agreeing to an Autodesk keynote. Despite being a competitor, we are all in the same space focused on advancing the industry for a better built environment tomorrow.

Most of the current value with IFC has been in the vertical industry with some horizontal work being done with the later versions (IFC 2×3,released 2006and 4, released 2015). Only now with 4.3.1.0 sent for ISO certification (4.3.0.0 was sent back with comments) do we have the opportunity to grow IFC within rail, road, and highway projects.

Most of the people I’ve encountered publish IFC because a governing agency or owner required it or for 3^rd party model coordination. Model coordination, analysis, audits, and QTO can be done with the native authoring application. For instance, a simple reference of Revit, SketchUp, and various other 3D files into OpenRoads Designer can be instantly shown and coordinated in 2D, profile, cross section, and 3D view or in sheets. Why publish to IFC? Because it’s open.

While many choose to pay for applications that consume IFC, the theory exists that one could develop free tools to use the IFC better. I, personally, have not encountered any free tools that did more than view a model as a pretty picture with manual data queries. Any of the tools with features worth using require ponying up some amount of cash.

What was most interesting to hear from Suchocki was a slide depicting the limitations of openBIM; how native formats and solutions are augmented by and not replaced by IFC. IFC works great with buildings, but geospatial information is lacking. There are current efforts to work IFC with CityGML/GIS to help with this. Security is also lacking with IFC. There is no way to sign and seal an IFC file. Native authoring applications have various levels of “sealing” a file. Carrying on the purpose of an original signature and seal of an engineer, a Bentley DGN file, for instance, can carry security certificates and lock down the data from any change. There are, however, ongoing efforts for a sort of wrapper that can be signed and sealed. Data or files can be stored within this wrapper, and the wrapper can lock down everything inside. This is independent of IFC. Security for IFC is a planned topic for future versions down the road.

Design to Design is also a common misconception with IFC as a supported use case. What Design to Design means is to develop a model in OpenRoads, publish an IFC, and then import the IFC for seamless continued design in Civil3D will likely not happen.

Once an authoring tool creates a model and an IFC is published, you cannot use that IFC and recreate the design from start. Roundtripping, as it’s often referred, requires the ability to define much more than what a published IFC currently provides. How each piece of geometry is calculated and drawn, and how each algorithm extrudes an object is different for every authoring application. IFC has always been a published snapshot of a finished product with model attribution. It itself, is not a continuable living file. It cannot be used to continue with design intent in different applications. It will also need a significant amount of work to handle something like parametric design.

Suchocki continues on that “IFC doesn’t necessarily mean that it will reduce time and increase simplicity. It might actually add more complexity with new skillsets required.” We’re seeing this now. It was certainly refreshing to see in an earlier slide, the values and criticisms of IFC. One of which being the files are too large. I’ve once seen a small road project with a file size of 10gb. Therefore, many applications are choosing to break up a particular design into several different files.

“It doesn’t compensate for the lack of planning, and it certainly does not guarantee that everyone will have a consistent experience.” This is certainly true for anything really. Technology and standards are only two pieces of the very complicated and intricate puzzle towards solving tomorrow’s infrastructure.

While IFC has many potential benefits, it’s important to convey the limitations and the realities of IFC, to have consistent messaging so that the continuation of IFC is not inhibited and detracted by the failures of false promises.

IFC in Bentley’s Products

I’ve stated in the last article that Bentley has been involved with BuildingSMART and has supported the many iterations of IFC in almost all of its platform products. Contrary to some opinions, IFC is not a competitor to Bentley’s solutions. We are continuing to support IFC today as we have been and don’t foresee letting that up anytime soon. Between our desktop and cloud-based support for IFC, we have anywhere from five to eight different versions supported. With version 4.3.1.0, we’re hoping to clean house and focus on (our best guess of) an official standard. Our best guess being that it is not an official standard yet. We really hope it will be soon.

As in the latest version of OpenRoads Designer, we are adding more functionality and useability to applying data to the models for IFC export. However, as with all desktop applications, the timeline between development, release, use, and feedback can stretch into months or even years timeframe.

At an earlier conference, someone asked, “When can I, as a Roadway Engineer in the US, expect to see IFC as a required deliverable on projects?”

This would be iterative, tested by governing agencies, and then mandated, likely on a project-per-project basis before it is widely accepted. To expect this as a useful mandated deliverable on all projects could be a few years from now on State DOT contracts. We currently expect ISO certification to occur sometime next year (of course we hope that future updates will occur faster). By the way, the current schema submitted for ISO certification doesn’t have items like storm drain. Everyone will still require the hijacking of building HVAC pipes for use in infrastructure pipes for quite a while.

Contrast to the typical product development cycle, Bentley also provides IFC export via our iTwin services. Since our iTwin services are cloud-based, updates to the schema can happen within days or weeks and instantly released without arduous software downloads and installs. Another advantage is that the IFC export can be a completely federated model from multiple vendors. This will ensure it’s a clean and consistent export. Rather than a single desktop application producing IFC from only their proprietary information, iTwin can be the aggregator of the information prior to IFC export. We are working on improving both the desktop and cloud-based IFC support, and are actively developing ways to make a better IFC more quickly.

In my own terms, I believe that IFC has the makings of a great omelet, but we’re still in the process of breaking some eggs to get there. The people I have met at this conference are some of the most passionate, smart, and hard-working individuals that I have ever met, all working toward a better future for the built environment. If you are so fortunate to ever attend, I highly recommend doing so. The next BuildingSMART conference will be in Rome on March 27 to March 30, 2023.