Clash Detection

Screenshot of the coordinated Navisworks model for the Lane Community College Health Professions Building, now under construction.

In the parlance of the construction industry a “clash” is the result of two elements in the design of a building unintentionally occupying the same space. An example may be a conflict between a duct and a beam, which both optimally would occur where their respective designers initially intend them to be but cannot. Clash detection is the process of identifying where such conflicts occur and how the systems interfere with one another. Ideally, the project team resolves these clashes before they become an issue in the field.

According to a McKinsey report, almost 30% of the overall construction cost on a typical project is attributable to inefficiencies in productivity and the need to resolve conflicts between the myriad systems that comprise a building. The design and construction processes are inherently complex undertakings, ever more so with each passing year. The probability of conflicts between building systems is only increasing as their complexity grows. Clash detection tools like Navisworks have thus become invaluable: the ability to compile data in a single platform greatly enhances overall coordination of a building’s design, reducing costs in the long run by flagging errors before they become an issue in the field.   

The Sheffield, UK company Lightwork Design Ltd. developed Navisworks back in 1997, eventually selling it to industry giant AutoDesk in 2007. Since then, Navisworks has become a de facto standard in the construction industry. AutoDesk’s Revit software has likewise dominated the Building Information Modeling (BIM) marketplace; the seamless interoperability of Navisworks and Revit has mutually enhanced their wholesale adoption by all members of the project team. I fully expect the two platforms will further converge into a single offering, additionally streamlining already available cloud-based, QA/QC, design collaboration, and integration processes.

In the past, clash detection too often occurred during construction rather than during the design or pre-construction processes. The result was the urgent need for design changes on the spot, inevitably leading to cessation and sometime scrapping of the involved work, with concomitant schedule delays. As you can imagine, such an occurrence comes with significant expense.

There are “hard” clashes and “soft” clashes. A hard clash occurs when two or more components are occupying the same space or otherwise interfering with one another. A soft clash indicates that an object lacks sufficient geometric tolerances; an example is an absence of sufficient space for maintenance purposes around an above-ceiling fan-coil unit. If the building design lacks such space, it triggers a soft clash. Geometry- and rule-based algorithms embedded with the BIM object provide the basis for detecting hard and soft clashes.

 

Clashes also occur in time. For example, failing to coordinate the required installation sequence of various building systems can lead to unnecessary removal and reinstallation of components, consequent wastage, and inevitable delays and cost overruns. Clash detection of this type relies upon the time data project stakeholders embed within the shared model (i.e., when deliveries of critical systems and components to the jobsite will occur).

Clash detection tools work by combining and coordinating many independently generated BIM models, such as those created by the architect, the structural engineer, the mechanical and electrical engineers, and the contractor’s design partners. In my experience, it is primarily the general contractor who coordinates and manages the combined model. Because of this, its use often occurs after the initial design work is complete but before shovels hit the ground. Ideally, all the members of a project team would share a single, federated BIM model as soon as detailed design begins; however, this remains more the exception than the rule (again, in my experience). With the increased proliferation of “non-traditional” project delivery methods (such as Design-Build, Construction Manager/General Contractor, and Integrated Project Delivery), this is changing, and quickly. The upshot is reliance on electronic collaboration and coordination tools, of which clash detection software is prominent, is increasing by leaps and bounds.

Another screenshot from a construction coordination session for the LCC Health Professions Building project. Note the large number of meeting participants. 

As I touched on earlier this year, the future of clash detection will inextricably be tied to developments in artificial intelligence. AI will lead to generative design tools that automatically route ductwork and piping to avoid conflicts with the building structure and other MEP elements. The AI algorithms will save enormous amounts of time. Though Navisworks presently allows stakeholders to comprehensively visualize project data in a coordinated 3D model, they still must resolve any identified conflicts manually. AI will largely obviate this burden by avoiding clashes from the get-go, while optimizing cost, embodied energy, energy performance, code compliance, etc. in the form of immediate and actionable feedback during all stages of design.

My point in writing this post is to offer readers not involved in design and construction a glimpse into one of the activities critical to the success of a building project today. In a nutshell, clash detection is essential to more efficient and error-free construction processes. Clash detection is synonymous with the prompt and seamless transfer of knowledge, design coordination, and team collaboration.