BIM model checker: IFC and BCF standard format analysis, key aspects and critical issues. The need for preliminary analysis of the actual verification activities (clash detection and code checking)
The verification and management of interferences and inconsistencies are fundamental activities for the development and implementation of a federated BIM model (digital model of multiple models created by individual specialistic teams).
These activities are defined as follows:
Clash Detection, definition:
identification and analysis of the possible geometrical interferences between objects in a 3D project model.
Model and Code Checking, definition:
analysis of the possible information inconsistencies of objects in a 3D project model with respect to standards and regulations.
Collaborative work and the BCF format
Construction industry design generally involves collaboration between different specialist teams.
During project revision, problems and errors may emerge and they need to be shared with the different members of the various teams. It can happen that each team works with its own software to create a digital model containing information relating to its field of expertise (eg structural, architectural, plant engineering, etc.).
A common format to facilitate communication between the various stakeholders involved is very important and the IFC format (previously described and analyzed in other articles of our blog) perfectly translates the concept of information which is merged and stored in a common language. After all, collaboration is far more straighforward where we all have the same understanding of the language we are using to communicate information with.
The IFC format contains data relating to modelled entities, but it is not a format designed to exchange document reports or workflows.
On the contrary, the BCF format is an open format that allows adding textual comments, screenshots and other information within the IFC model. This is to ensure better communication between the various groups involved in the implementation of a project.
The BCF is a format proposed by various software houses in 2009 and aims to be an open standard able to guarantee communication flows between the various BIM based software solutions.
It enables an orderly and effective method of communication that is fully traceable and that is separated from the digital model in IFC format, but at the same time it can be integrated into it, to allow the coordination of the various teams in a design process.
The BCF file is a compressed file that contains a folder for each detected interference / inconsistency. Within this archive there are 3 types of files with the task of transmitting all the information needed to identify the problem in a univocal way.
- the MARKUP, which is a file containing textual information about the IFC file with the model, the author of the report, the entities involved and the comments necessary to solve the problem;
- the VIEWPOINT, points of view that frame the problem directly found on the digital model. They can be multiple and can be linked to the comments contained in the Markup;
- the SNAPSHOT, problem images connected to the points of view identified within the digital model.
Critical issues regarding the IFC format and model prerequisites for creating customizable Rule sets
Use of the IFC format is often accompanied by doubts about its reliability are frequent. A common question is: “When exporting to the IFC format, is there any risk of losing data?”.
Scientific research on IFC format is usually conducted with a sequential test. The principle is simple: an IFC file is imported into BIM based software, then immediately exported to a new IFC file.
Another BIM based software imports this file and performs the same sequence of operations.
After a series of imports and exports between different BIM software, if the conversion of IFC entities into proprietary entities in the software is 100% functional, the resulting model must be identical to the initial source model.
The IFC format is not designed to transmit the concept of parameters and components, but to make the exchange of (geometric and alphanumeric) information possible between the various professionals who find themselves collaborating during the development of a project.
This means that it’s far more correct to think of the IFC format as a snapshot of the project, which frames the digital model at a certain moment and from a certain point of view, and from the discipline that generated it.
It is therefore good to have a tool that analyzes the BIM model (or even federations of models) and can verify the presence of certain information or essential geometric requirements, depending on the use the model was intended for.
The BCF format allows us to:
- communicate any inconsistencies found,
- share them in the form of reports to request a modification of the digital model (to be carried out in the used BIM authoring software) and a re-share of the same in IFC format.
Critical aspects and activities prior to verification
Let’s assume that we have a model in IFC format that needs to be submitted to clash detection or code checking activities.
Before proceeding you should be able to verify that the IFC file is formally correct and does not present geometrical and/or informative defects.
However, it would be interesting to have software that allows to carry out the necessary preliminary evaluations, with the following functionalities:
- timely redefinition of the geometry: possibility to redefine the geometry of an element exported in IFC format, without the need to rework the entire digital model. Let’s talk about point redefinitions and not about the possibility of completely remodelling the entity; for these last activities BIM authoring software is already used.
- addition/correction of information: possibility to add information to entities or correct any incorrect information. This opportunity would ensure speed up the flow of creation of a federated digital model. In fact, at the moment a requested datum is not present in the IFC model, it is impossible to have the numeric or alphanumeric value to be verified and subjected to our verification Rule set. However, some information (missing or incorrect) could be deduced directly from our digital model thanks to specific tools.
- creation of relationships: the possibility of making changes to relationships, such as creating a hierarchy between entities or establishing correspondences between elements based on their parameter values , facilitates the verification process.
Model checking activity
Once these preliminary assessments have been made and any inconsistencies found corrected, we can proceed to the well-known model checking activities:
The Clash Detection workflow consists in verifying the geometrical interferences between BIM objects. It’s the process of identifying elements that collide with each other. These entities can collide for various reasons, obtaining different types of clash detection errors:
- hard clash: elements that occupy the same physical space, such as the case of a beam or a column running through a window. In this case, the reprocessing of one or more compared digital models may be necessary;
- soft clash: the elements are incompatible from a geometric point of view, because they invade the mutual space necessary for assembly or maintenance. In this case, conflict resolution can be postponed to resolution during the build phase, without having to modify/update the digital models;
- 4D/workflow clash: elements that are temporally and mutually inadmissible; for example, of a piece of furniture that, due to its size, must be introduced into an environment before the partitions are completed. In this case it is appropriate to resolve the issue by opening a markup in correspondence with the elements involved, without needing to update or modify the digital models.
The Code checking consists of the verification of information inconsistencies and rules to which our digital model must meet, with the identification of inconsistencies with:
- prescriptions from the EIR (Employer Information Requirement) or BIM Execution Plan: cases in which some criteria of correct modelling could be violated or specific properties requested in the documents could be absent;
- specific technical rules or regulations: in this case, regulatory or regulatory technical requirements may be violated (eg minimum heights to achieve the accessibility of the premises, access widths, safety distances, etc.);
- custom criteria: in this case, the requirements or requirements defined by the designer/customer may be violated (eg: presence of elements necessary for the correct use of the building, presence of guard rails in correspondence with windows, etc.).
Any inconsistencies must obviously be represented graphically or in a table, allowing the technical design team to easily identify errors and make the necessary changes.
The results of the detected problems analysis phase is shared by viewing each error together with the relating description in the different BCF standard formats or in an Excel or PDF file format.