- Cas d'utilisation
- Co-Creation Space
Communauté
Organisations
Partenaires de collaboration
- Connexion
All dokuments are licensed as a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
(Attribution-Non-Commercial-ShareAlike 4.0). Further information can be found at
The documents reflect the current best practice and do not claim to be complete. They should not to be understood in the sense of a generally valid recommendation or guideline from a legal point of view. The documents are intended to support appointing and appointed parties in the application of the BIM method. The documents must be adapted to the specific project requirements in each case. The examples listed do not claim to be complete. Its information is based on findings from practical experience and is accordingly to be understood as best practice and not universally applicable. Since we are in a phase in which definitions are only emerging, the publisher cannot guarantee the correctness of individual contents.
PAS ENCORE INSCRIT?
Inscrivez-vous au Service de Gestion des Cas d'Utilisation gratuitement pour commencer à créer votre premier cas d'utilisation.
Les utilisateurs inscrits peuvent utiliser la zone de téléchargement et les fonctions de commentaire.
Clash detection is a procedure for detecting geometrical collisions between model elements of different disciplines and BIM models. It is an automated process where two or more models can be checked for these collisions using specified rules and tolerances. Clash detection is an integral component of the BIM process. It improves coordination between disciplines and has the overall effect of reducing costs and mistakes in a project.
The proposed use case aims to perform clash detection analysis between BIM models in an automated, rule-based manner.
This procedure is an important step in the BIM collaboration process. Having multiple designers working on different models leaves room for error, where different elements can clash, meaning at least part of one element collides with another at the same location or that certain tolerances are exceeded. These clashes can be checked automatically through tools using models and clash detection rules as input. These rules are created for determining what kind of object collisions will be understood to be clashes as well as any tolerances an element has. After the program automatically checks two or more models against each other for clashes, designers or coordinators have to go through them and confirm if they are indeed clashes and find a solution to fix them.
Clash detection should have the overall effect of:
Individual clashes detected by the program must be analyzed manually by the designer who must decide if each one is relevant. The clashes will need to be fixed by the responsible designers.
IFC: Industry Foundation Class
Clash detection relies on openBIM format IFC files which are exported from authoring software. These IFC files are then uploaded into the Clash Detection software being used. These are then checked against other models using the software’s clash detection tool. After performing the clash detection, issues are created and shared to relevant project participants where they will help coordinate fixing model geometry. If the users are working within the same collaboration environment, they may not need to exchange any files, however if they are not, then BCF files including information on the clashes may be exchanged between users, which can then be read into authoring software.
In this phase the following items should be discussed and documented:
This process is necessary to be able to program the rules into a clash detection software.
Before performing clash detection all the models need to undergo quality checks in order to determine whether they meet minimum requirements for clash detection at a given stage.
The most common indicators of model quality are:
It is advised to use a standard model quality checklist before every clash detection session.
As soon as the models are checked and ready, the clash detection can start.
All the identified issues should be discussed and resolved by designers. The next iterations of updated models are undergoing clash detection multiple times in order to limit the number of clashes to a minimum. If the clash is resolved, then the respective issue should be closed.
The central issue register on cloud platform helps to manage and document the whole process.
The following demonstration case, part of the European Project BIM-SPEED, is a renovation project for an underground passage located in Warsaw, Poland near Rondo Jazdy Polskiej. The currently unused passage will be deeply renovated and become a point of first contact for homeless people. The design process produced multiple discipline models including an architectural, structural, various installations, and site plan models. It was vital to accurately check models against each other in order to reduce future delays when construction begins as well as keep the project on budget for the City of Warsaw.
Before performing clash detection all the models used underwent quality checks.
It is advised to use a standard model quality check list before every clash detection session.
Firstly, all the models were loaded in order to create a federated model. The software used was BIMCollab ZOOM. Models were uploaded to the shared project by their respective users. They were also responsible for updating the models, as required.
Then the programmed clash rules were executed:
Each clash was analyzed separately. Only if the clash was relevant, was it reported:
Each clash or group of clashes is then reported as an issue:
All the communicated issues formed part of an issue register:
Issues are then synchronized to a cloud platform and communicated to respective discipline designers using BCF file formats.
Reports of the number of clashes and issues are being regularly created to verify the progress of 3D coordination:
All the identified issues were discussed and resolved by relevant designers. The entire process was iterative, with each subsequent updated model being checked against the rest each time. When the clash was resolved, then the respective issue was closed and archived.
During several iterations of clash detection, a total of 148 issues were identified and communicated to the lead designers.
It should be decided during this stage if clash detection between models will be a requirement later on in the design phase. If there are multiple models, especially when created by designers of different disciplines, it is highly recommended to perform clash detection. Procedures for how often and who is responsible for clash detection should also be outlined, for example in a BIM Execution Plan.
This is the stage when clash detection actually occurs, as outlined in the above procedure. It is an integral part of the coordination process in a project that makes use of BIM models.