What are the limits of an IFC format? Let’s analyze some of the features to understand the correct use of an IFC file
The characteristics of the IFC file format may present various types of limitations due to inappropriate use in relation to the purposes for which it was developed.
Saving a BIM model in IFC format allows all BIM role players to transfer the designed Building’s data set from one platform to another (even data that isn’t covered in the standard), even if, exporting objects that are composed parametrically is not allowed.
It goes without saying, that from a graphical point of view, most objects are exported as “Models”. These are viewable and linked with specific object information that is assigned in the software that generated them. Once exported they can’t be further modified parametrically.
This is in accordance with the buildingSMART International, guidelines, the international body that has developed and maintains the IFC format. BSI also deals with checking the compliance of IFC files produced by the software houses that request import/export process certification, and issue certification after an intense validation process.
By definition, appropriate use of the IFC format is to allow one-way communication between the authors of the various models. This is also clearly displayed in the figure below. It shows that discipline can generate a single “transfer” model (in IFC format) that in a unidirectional way is directed towards the various other disciplines and areas of competence.
The advantages of using IFC files
In this digital design and construction scenario, it’s now possible to put the various models together to carry out coordination, or use the Architectural model, saved in IFC format, as a reference to study and generate the strutural model or the HVAC systems design.
The final IFC file can therefore serve as an archive to be delivered to the client for further EIR (Employers Information Requirements) assessment and validation.
The alternative to overcoming all kinds of limitations due to proprietary technology, can only be the introduction of an open format (IFC, etc.) in order to understand all of the functionalities of the various Authoring software now avaialble on the market. Ideally, development of formats that go in different directions should be halted so that this hypothetical non-proprietary format can be effective for all proprietary software indefinitely over time. An impractical scenario in a world that grows through research, innovation and technological progress.
However, in the Public Procurement sector, we can’t simply accept the co-existence of proprietary and non-proprietary file formats because we would end up using files deriving from licensed software, much richer in terms of functionalities and in constant evolution. Most Local Authorities would end up with project files whose real owners would be the companies that develop the authoring software they were created with.
In this respect, we are dealing with a true technological revolution that changes the way we work by introducing new tools and processes to adpat to.