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.
.png)
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.