By Alan Esguerra, Industry Strategy Manager
buildingSMART hosted their International Standards summit in Lillestrøm, just outside of Oslo, Norway in September of 2023.
The summit focused on delivering “Digital Products and the openBIM® Workflow” and attracted around 450 in-person attendees with close to half as much in virtual attendees. Attendees came from around 39 countries. There was an emphasis on various workflows that include not only IFC, but a plethora of other solutions and technology, to come together and provide a path forward. Many discussed various aspects of digital twins and how they’re progressing towards a smarter and more uniform approach to engineering project delivery.
Technology Updates: MVD, IDS, and BSDD
In my first article on IFC, I briefly described what Model View Definitions (MVD) are, in simplified terms, as a standardized subset of data for a particular use case. The way it is described and has evolved is not quite as sustainable as described by buildingSMART’s Leon VanBerlo.
For the infrastructure transportation world, there are really only two active developments on the MVD front making progress: Reference View (RV) and Alignment-based Reference View (AbRV). These MVD’s are similar to how MicroStation can reference many file formats from Autodesk and Revit to Sketchup and GIS Shape files to not only view the geometry, but also the property information within them. Alignment-based Reference View was introduced for bridges to allow for referencing with information based on alignment. This is similar to how OpenRoads can reference files, base readings, and measurements off of a referenced alignment.
While commonly requested, Design Transfer View MVD is unlikely to happen in the current version of IFC, where one can create a Civil 3D file, export an IFC, and import it into OpenRoads Designer. As described in multiple sessions by other software vendors such as Marek Suchoski of Autodesk, the current state of IFC does not have the “guts” to define how any of these model objects are built. It does not contain the requirements for design intent to transfer. Asset Handover is another MVD that is currently considered, but is far behind the RV and AbRV MVD’s.
During this conference, there was a spotlight on two specific items. An Information Delivery Specification (IDS) and the buildingSMART Data Dictionary (BSDD).
The IDS serves as a sort of “restrictor” or “checker” file that states, “I want to make sure my IFC file has X class and Y property set.”. This file is a simple XML file that is computer readable. Then one would take the IFC file and say, “Please check if the IFC file conforms to this IDS”. The IDS does not guarantee the quality of the design model, just that the IFC conforms to an organization’s or a project’s IDS file.
The BSDD is an online repository of definitions that organizations can use to help their users follow a consistent and standard workflow to guarantee data quality, information consistency, and interoperability. It can also be used to define other classifications outside of buildingSMART that one would want to employ on a regular basis. It’s like a live lookup for an authoring application to apply the latest and greatest properties to a model object.
For support, Bentley imports, references, and exports various forms of IFC, but as of yet does not create an IDS or connect to the BSDD since its still relatively new. For the IDS, it makes sense to be able to have some way to check against a requirement. I think this is a step in building confidence and checking consistency in design models. On the flip side, I can also see how some organizations may create massive mega IDS files that designers will find it easier to find ways to skirt the system to pass an IDS check rather than fix the model. This seems similar to how some organizations use Spec Checker for CADD level symbology compliance to an outlandish degree where there is a diminishing level of return for compliance. It may be prudent for practitioners ease into using IDS before any kind of mandates.
Should the IDS come from the designer or should it come from the owner that must define the requirement or both? Is there enough value in having an IDS come from the authoring software or is there more value if the specifications came from an independent source similar to verifying any design calculations, methods, or checks are done independently.
While the need to define a common data dictionary in a uniform format is quite helpful, would a requirement for a live link to the BSDD from a design application be necessary? How often would it change? If it does change, should it be in a controlled manner? For instance, the American Association of State Highway and Transportation Officials (AASHTO) may have a data dictionary for bridges and may label it “2.0”. If new “2.1” requirements are added in the middle of the project, should all projects now read the live BSDD and conform to “2.1” or should the project be finished out in “2.0” and the next project will start with “2.1”? With Bentley software’s ability to define IFC data with Item Types, the best path forward may be an occasional push from BSDD to feed an Item Type workspace rather than a live link.
IFC as a Requirement – Is it Enough?
I was fortunate to be included in a vendor panel where one of the attendees had mentioned that the first US requirement of IFC may come out in 2024. As IFC is still quite new to the US market, I suspect that this will likely start as a small portion on a bridge project as most of the progress to date has been only on bridges. This led me to ask, “How are some agencies and countries are getting along with IFC as a requirement?”
Some countries still only require 2D plansets to the contractor but require IFC as an internal coordination submission between the designer and the owner. Other countries are blazing the way forward with IFC and are extending IFC to suit their needs. These countries are adding onto IFC to suit their needs and creating their own extensions which make it more useful for their organization. Some private companies are taking advantage of how open IFC is and creating toolsets and workflows around this data. The downside is that use will be exclusive to them. China, for instance, is making their way with their CN-IFC version based on IFC 4.3.
I was surprised to learn that Singapore’s Building and Construction Authority, which deals mostly in the vertical building space, are transitioning to a model-only bidding system called Corenet X. From the presentation, they used to allow for both 2D and model-based bids on certain projects through their online-only platform. They’ve hosted multiple webinars, industry events, and trainings to help transition their marketto this new regulatory approval and data requirement process. They will utilize IFC as a core requirement for the bidding process. Since IFC does not support some projected coordinate systems and units of measure still in use, I’m sure BCA has a plan to address this. Many of the attendees I talked expressed how IFC is just one file of many requirements that will be required.
I’m sure there are many lessons that can be learned from their practices, however I’m also sure there are many tasks that will only apply to them. When one attendee asked, “What will happen to the small construction firms that do not do BIM or model and only rely on 2D plans?” The response was, “Then they will go out of business if they do not learn.” I struggle to see the same kind of swiftness from a smaller nation state be applied to the US, but I can see their point. I think the key ingredient to their push was making sure the industry was well educated before mandating while I’m sure much needed grace will be required through the transition.
Still right now, IFC 4.3 is a published static file that can help feed one part of a digital twin, but certainly is not evergreen without much effort. As discussions of live, or nearly live, evergreen digital twins are coming to the forefront, I can’t help but to reflect on the benefits of moving towards a data centric workflow rather than a file centric workflow. In trying to get a sneak peak of IFC 5 through some of the sessions, it looks very similar to iTwin.JS. IFC 5 seems as if it’s moving away from a file format and towards a database style as they define the tasks that they should or should not do while the workshops debate what should be a priority. My feeling is that progress will be made over the next decade on IFC 5 and I look forward to what they develop. As the industry moves forward, I am confident there will be many lessons to learn and share in the future.
Education on OpenBIM
Project manager training now available in the United States through Strategic Building Innovation.
There are a few other official professional certifications around the world, but for most practitioners, the U.S. course includes the Foundation Class and now the Project Contract Management Class. For the applications side, there is an OpenBIM Applications Course and a Virtual Design and Construction Course (VDC) also offered by SBI.
Latest Bentley Support for IFC
In the past, OpenCivil (OpenRoads and OpenRail), exported only alignments and corridors. However, some users needed more than just the alignments and corridors. OpenBuildings offers a set of IFC related tools of which some users would use in conjunction with our civil applications. As this process was quite arduous, many didn’t use it. Then came the iTwin method where multiple different file types can be loaded into an iModel and an IFC can be exported. With this method, IFC mapping had to be done through a JSON file as mentioned in my previous articles. This too was not very user friendly. The need to upload your model to the cloud also presented another adoption blocker.
In the next version of Bentley’s Civil Applications, we are debuting a new method of exporting IFC with the use of Item Types. With this new method, we are consolidating the way we export IFC files by relying on iTwin technology. Now, item types can be automated, semi-automated, or manually placed on any 2D or 3Dobject within Bentley’s authoring tools. The ad-hoc exporter will download the latest iTwin connector and IFC exporter from the cloud and do all the work on their local machine. No data will leave the machine. No data will be uploaded to the cloud. Users can even export IFC files on airplane mode.
This method also has another big advantage. As IFC evolves, we can export the new data structure faster and more efficiently without having to wait for the typical software development lifecycle. No more waiting for the next version of OpenRoads Designer to export the latest IFC schema! As soon as the IFC exporter on the cloud is updated, both the desktop and iTwin workflows will utilize the same technology. We feel that focusing on this method will allow us to be more adaptable and more consistent in how our products export IFC files.
For my previous articles regarding IFC, please see the links below:
