Importance of IFC in BIM
Please fill out the Download Section (Click here) below the Comment Section to download the midas CIM - Bridge Information Modeling (BrIM) software
Table of Contents
3. Why is IFC important for the AEC industry?
5. How is IFC implemented in Bridges?
6. Midas CIM & IFC Compatibility
Some believe that the construction sector lags behind other sectors in implementing new technology and methods of operation. Ensuring that people, processes, information, and systems are connected and integrated successfully is important. The benefits of achieving this include, but are not limited to, lower overall construction project costs, improved project management skills, and sharing key information with project stakeholders during the design, construction, and operation stages. Building information modeling (BIM) is acknowledged as a solution that will enable and promote these advantages.
Digital technologies supported by a collaborative work system known as BIM make it possible to design, construct, and manage physically built assets more effectively throughout their lifetimes. Direct data transfer between BIM models utilized by various stakeholders is somewhat challenging. Additionally, simply transferring models and data between software takes time and necessitates specialized solutions from each software producer.
We can see that a standard language for data transfer is essential. This is taken care of in the context of BIM by the IFC (Industry Foundation Class) standard, which is an open standard and would serve as the foundation for BIM data exchange methods and stakeholder communication.
IFC (Industry Foundation Classes) is an international standard schema progressed by buildingSMART.
BuildingSMART, formerly known as the International Alliance for Interoperability (IAI), is a global organization with the mission of enhancing information flow across software programs used in the building sector. BuildingSMART developed the IFC file and its standard to create a globally standardized tool that could support and monitor construction progress and the life cycle of buildings (even bridges and infrastructural objects) from the concept and design through construction to operation, even demolition.
Given that the IFC schema has a defined International Standard (ISO 16739:2013), asset managers and stakeholders in the AEC have acknowledged the value of following this standard for data sharing.
Many concepts may be digitally described using IFC data, including:
Physical objects in our built environment
Geometric representations of real objects in 2D and 3D.
A wide range of properties and attributes across several domains
Material characteristics and color displays
Planning, scheduling, and distribution of resources for construction
Quantification of components
Roles and responsibilities of individuals and organizations.
Analytical models for structural analysis
The additional information that can be kept within IFC is where it becomes significantly more interesting. IFC is a hierarchical standard in which each class builds on the previous one. The IFCRoad class, for instance, is one of the classes that could be present in an IFC file. It is constructed from several classes and includes its original data. In reality, this implies that when searching an IFC file for an item for an IFCRoad, we may extract details specific to that class, including the number of lanes on the road and the maximum speed it can support. Because this road is based on the more basic class IFCSpatialStructuralElement, we may also infer information about it, such as its location in the world or its length, breadth, and depth.
The required IFC data can be encoded in various formats, such as XML, JSON, or STEP, and sent via web services, imported/exported as files, or managed in centralized or connected databases.
In reality, interoperability implies that all data is arranged in open, standard forms that any vendor may learn about and include in their offers. Furthermore, clients may select the appropriate solution for their needs at each stage of the process and be confident that their data will flow as expected. Interoperability is a deciding factor for potential consumers when picking which software to use.
As AEC firms utilize various software systems to design, commission, and run assets, sharing this data can be problematic. This is mainly because each software manufacturer has a file format incompatible with other AEC design software products.
The IFC standard was created to promote effective data sharing between AEC parties and asset managers. Thanks to the IFC-compliant Common Data Environment (CDE), all project participants may now transparently share information. The IFC standard allows information to be communicated in a way that facilitates and encourages interoperability. IFC allows engineers, architects, construction companies, and asset managers to exchange AEC data.
Owners may request architects for new project designs, contractors can ask for those designs, and architects can provide as-built models with specifics on installed equipment and manufacturer information. Contractors can also deliver these as-built models to owners once the project is completed.
End users can export, import, and transfer data in the IFC format via interfaces offered by CAD/BIM authoring software platform vendors. If a user wants to share anything from one of their tools with another, they may do so via IFC. This dynamic data format, known as IFC, aids in the organization of model data and promotes collaboration among all project members.
Currently, there are three commonly supported versions of IFC: IFC2X3, IFC4, and most recently IFC4.3.
Many BIM writers are accustomed to exporting and exchanging models using IFC2x3. Since 2005, IFC2X3 has been an ISO standard.
Despite being an ISO standard since 2013, IFC4 has been progressively integrated into BIM authoring software. Compared to IFC2X3, IFC4 has numerous additional capabilities, such as enhanced geometry representations, geolocation capability, and more element types.
In March 2022, IFC4.3 became an ISO standard, extending IFC4 to be more suitable for linear infrastructure (Roads, Railways, Bridges, Earthworks, Geotechnics, Ports & Waterways)
Until the introduction of the IFC 4.3 scheme, transportation infrastructure was inadequately represented in the IFC framework. Of course, it was and still is feasible to create a file containing a BIM model based on IFC 2x3. The objects used to display individual elements, on the other hand, are quite general and include little further information relevant to this sector. In the IFC 2x3 scheme, for example, the pavement layers in the road model are specified with ifcSlab and ifcBeam. We can only meet a vertical division of a building project, with distinct levels represented by spatial objects like ifcBuilding and ifcBuildngStorey. Fig.1 is a depiction of domains that fall under IFC 4.3.
Fig. 1 - Representation of domains under IFC 4.3
IFC Scheme 4.3 is the first to offer a comprehensive set of definitions for presenting a construction project in an organized manner for the infrastructure industry. The IFC 4.3 program was created to expand IFC advantages to what is known as horizontal assets. That is an infrastructure that spans over the terrain, such as roads and railways, as well as all the characteristics that go with it. The IFC 4.3 program's complete scope includes Road, Railway, Ports & Waterways, Bridge, and the common features connecting all these. Each domain has a wide range of use cases that they want to cover using the IFC schema.
A road is a linear item part of a wider road network, such as national roads, provincial highways, etc. Many associated elements, such as tunnels, road junctions, and bridges, are positioned along the line of the road structure. Each of these fields entails the design and building of various other objects. These structures are collectively known as ifcFacility, and the distinct types of structures are as follows:
ifcBridge
ifcRailway
ifcRoad
ifcBuilding
ifcMarineFacility
According to BuildingSMART International, which has a list of specifications and a certification procedure, IFC data import and export protocols must be performed correctly to ensure compliance with the standards. All IFC-certified programs, according to buildingSMART, are capable of reading, writing, and exchanging data with other software solutions.
So, you've probably heard of the Midas CIM, a bridge information modeling platform. Midas CIM is also IFC compliant. CIM may import data from any other IFC-compatible software. Similarly, all data from CIM may be exported as IFC files. CIM is currently compatible with the IFC 4 version.
Let us now view an example of CIM compatibility with various BIM platforms. In Fig. 2, we can see that a CIM-modelled pier substructure is exported as IFC. The IFC file is then loaded into the Revit software. All the properties of the pier substructure are transferred to Revit. Thus, CIM facilitates data transmission with all other IFC-compliant platforms.
Fig. 2 – Interoperability between Midas CIM and Revit using IFC
Adopting the IFC standard will save architects, engineers, construction businesses, capital project investors, and asset managers substantial time and money. These advantages have been realized in experimental projects where the IFC schema enabled building projects to be completed ahead of schedule and under budget. With this universally agreed-upon standard to build on, the software can become more interoperable by speaking the same language, new services may emerge that make interoperability seamless, and all users benefit from the tools at their disposal to decrease costs and develop better.