Recently, there has been a lot of discussion surrounding the advancements in the IFC 4.3 standard. One of the most significant changes is its support for the infrastructure industry. Using the IFC classes in the latest version of the standard, it is possible to describe a significant portion of the objects present in linear infrastructure projects. I have written about this in the article found at this link: LINK. This marks a crucial step towards standardizing the exchange of data in the infrastructure industry.
Another advantage is the closer alignment with the construction industry and the potential for co-creating common processes throughout the project life cycle (Supply Chain).
Initially, it appears that the greatest beneficiaries of the implementation of IFC 4.3 will be design companies and asset managers.
In this article, we examine the impact of this standard on construction contractors.
Can infrastructure contractors effectively use data stored in the IFC format?
Please find more information in the article.
Contract model and BIM
There are various contract models in the construction industry, with the most prevalent being the DBB (Design-Bid-Build) and DB (Design-Build) models. I have written about contracts, among other topics, in this article: LINK.
In Design-Bid-Build contracts, the entire project is divided into several stages and agreements are concluded between the appointing party and the appointed party before each stage. The most common contracts are for design and construction works, but there may also be a pre-design (concept) phase preceding the design phase, which is also preceded by a contract.
In the DB model, there is only one contract between the appointing party and the entity representing the contractor, covering both design and execution works.
Why is it important? The contract model affects the collaboration between the designer and contractor in the project. In DBB contracts, the quality of the design documentation provided to the contractor may be insufficient (e.g. it only consists of flat 2D drawings and DWG files), making digital data inadequate for execution works. This is due to the absence of provisions in the contract regarding the contents and purpose of the digital documentation.
In DB contracts, the situation is much simpler as the contractor instructs the design company (as a subcontractor) on the appropriate data and format for him. This contract model is more favorable for creating seamless data transfer processes between the design office and the construction site.
IFC is not a file!
To be honest, in my previous articles about IFC, I primarily focused on gaining a better understanding of the purpose and benefits of using IFC for myself
The articles stem from my thought process and evolution of understanding. Initially, I viewed IFC as just a file format, but I soon realized that it is much more than that. I was corrected by the CTO of buildingSMART himself when he pointed out that my statement of “IFC being just a file” was spreading misinformation.
IFC, or Industry Foundation Class, is actually a data classification/standard/scheme that allows for the classification of digital objects in a building information model (BIM) project. This standard provides a framework for describing objects in a construction project, such as curb, roadway, shoulder, sidewalk, foundation, barrier, marking, ditch, slope, earthworks, and more. The IFC 4.3 standard offers a common vocabulary and naming convention, as well as the ability to add non-geometric data to objects, making it a valuable tool for designers in the infrastructure industry.
IFC in Design-Bid-Build
Let’s go back to the DBB contract again.
Let me make the following thesis:
“Design documentation delivered in the form of IFC4.3 standard files in DBB contracts increases the level of utilization of this data at the construction site by X%.”
In the context of a design works contract, the appointing authority includes provisions regarding the composition of the design documentation. It is common for the ordering party, in addition to paper documentation, to expect files that can be displayed in a “BIM viewer.” Additionally, it often occurs that the contract agreement does not include provisions regarding the intended use of the data received by the contracting authority. This leads to the situation where the data created during the design phase is not utilized to its full potential on the construction site.
It’s all about legislative matters. Currently, IFC is not a mandatory format for project documentation in infrastructure contracts due to its shortcomings in this area. However, this is all set to change with the completion of the ISO certification of the IFC 4.3 standard. Thanks to this achievement, the IFC format, as an open standard that supports infrastructure, will be able to be required in public tenders!
IFC on construction site
Let’s take a look at what information the construction company needs on the job site.
It ultimately comes down to two categories of models: existing models and discipline models. I’ve written about them in this article: LINK
- Terrain surface model
- Layers in the ground
- Rock surface model* (especially important for Scandinavia)
- Road model – surfaces, solids, lines
- Sewerage model – detail, trench
- Geotechnical model – surface, detail
- Landscape model
- Electric model – ditch, detail,
- Marking model
- Construction model – formwork, digital reinforcement
- Tunnel model – plan of explosions,
- Protection against water and frost
- Environment model – Drilling ground protection plans,
- Road model, surfaces, lines
- Sewerage model, ditch – surfaces
- Geotechnical model, surfaces
- Landscape model, surfaces
- Electric model, ditch – surfaces
- Model of the sewage system, location of manholes
- Geotechnical model, pile reinforcements
- Electrical model, cable location
- Marking model, posts, signs
- Electric model in the tunnel
- Tunnel model, formwork
Usability analysis of IFC 4.3 on site
Let’s move on to the last point, where I will analyze whether IFC 4.3 is ready to become a “game changer” in the infrastructure and construction industry.
Looking at the examples from the previous point, we can conclude that contractors mainly care about good geometry. In most cases, this involves the use of many file formats. I wrote about the file formats used in digital projects, among others, in this article: LINK
This is because, for example, typical road geometry, i.e. the alignment (route line), was stored in LandXML standards, while this definition was not previously present in the IFC or DWG standard.
And here we can talk about another milestone, namely the inclusion of the alignment definition in the IFC 4.3 standard. This change will allow the road model to be sent directly from the design office to the construction site without the need for creating many formats.
Among other things, this is because the geometry contained in IFC 4.3 can be successfully used on construction devices. (Advanced work is already underway at Trimble to be able to handle the standard in applications such as Trimble Access)
The IFC 4.3 standard has a rich representation of geometry, the ability to name infrastructure objects according to a convention accepted by all participants in the construction process (the ISO standard), and the ability to assign non-geometric data in the form of PSets.
In conclusion, I believe that the introduction of the IFC 4.3 standard is a milestone towards increasing efficiency on the construction site. For example, only one open format that can be required by the client can be used throughout the project’s lifecycle. In my opinion, the construction industry will quickly adapt if it turns out that software and construction equipment suppliers (machine control systems, “surveying rods”) begin to support the IFC 4.3 format.