Clash Detection en Proyectos BIM: tipos de interferencia, proceso y límites

Entienda qué es Clash Detection, los tipos de interferencia, cómo configurar pruebas, controlar issues y por qué detectar colisiones no sustituye la compatibilización.

¡Descúbrelo!

Clash Detection es el proceso automatizado o semiautomatizado de comparar elementos de modelos tridimensionales para identificar colisiones, superposiciones, violaciones de distancias mínimas y otras interferencias previamente definidas. En proyectos BIM, permite localizar conflictos entre arquitectura, estructura, instalaciones, infraestructura y sistemas antes de que estos problemas lleguen a la ejecución.

Sin embargo, la detección por sí sola no resuelve la compatibilización. El software señala ocurrencias según los modelos, selecciones, reglas y tolerancias configuradas; el equipo técnico debe interpretar cada resultado, eliminar falsos positivos, agrupar ocurrencias repetidas, asignar responsables, evaluar impactos y verificar la corrección en las revisiones siguientes.

Por eso, el valor del Clash Detection no está en la cantidad de colisiones generadas, sino en la capacidad de transformar resultados geométricos en decisiones técnicas trazables. Un proceso mal configurado puede producir miles de registros irrelevantes. Un proceso bien gobernado concentra el análisis en las interfaces críticas y reduce retrabajos, improvisaciones, retrasos y riesgos de implantación.

En este artículo, el término se trata en el contexto de proyectos de ingeniería y BIM. El foco no es una herramienta específica, sino el método para preparar modelos, configurar pruebas, clasificar interferencias, controlar ocurrencias e integrar la detección en el proceso más amplio de compatibilización.

Qué es Clash Detection en proyectos BIM

Clash Detection, o detección de interferencias, es el análisis computacional de la relación espacial entre conjuntos de elementos de uno o más modelos. La herramienta verifica si los objetos se intersectan o incumplen condiciones geométricas configuradas, como distancias mínimas, envolventes de mantenimiento y zonas de seguridad.

El análisis puede ejecutarse en un modelo federado, que reúne modelos disciplinares sin retirar la autoría de cada proyectista. Arquitectura, estructura, electricidad, hidráulica, climatización, protección contra incendios, automatización, seguridad electrónica, telecomunicaciones y otras disciplinas permanecen separadas, pero se visualizan y comparan en conjunto.

El resultado típico es una lista de ocurrencias asociadas a elementos, ubicación, visualización, prueba de origen y estado. Dependiendo de la plataforma, cada ocurrencia puede recibir comentario, prioridad, responsable, plazo, imagen, viewpoint, clasificación e historial de tratamiento.

Hard clash: colisión física

El hard clash ocurre cuando dos geometrías ocupan el mismo espacio. Algunos ejemplos son:

conducto de climatización atravesando una viga;
bandeja portacables cruzando tubería;
luminaria superpuesta a un sprinkler;
conducto eléctrico atravesando un equipo;
cámara insertada en un elemento estructural;
cuadro eléctrico ocupando un área destinada a una puerta;
tubería penetrando un shaft fuera de la abertura prevista.

Es el tipo más evidente, pero no toda intersección representa un error. Los elementos que deben conectarse, penetrar o superponerse pueden generar colisiones legítimas. Por eso, la prueba debe definir correctamente qué conjuntos serán comparados y qué excepciones deben considerarse.

Soft clash: separación o espacio libre insuficiente

El soft clash ocurre cuando los elementos no se intersectan, pero incumplen una distancia mínima. La regla puede representar:

espacio de mantenimiento;
zona de apertura de puertas y paneles;
distancia de seguridad eléctrica;
segregación entre energía y telecomunicaciones;
separación respecto de fuentes de calor;
espacio para retirar filtros, módulos o baterías;
área de giro o movimiento de equipos;
envolvente de acceso para personal y herramientas.

Este tipo exige una tolerancia técnicamente definida. Una distancia arbitraria produce resultados sin significado. El valor debe provenir de un requisito, norma, fabricante, procedimiento de mantenimiento, criterio del propietario o análisis de riesgo.

Clash de duplicidad o superposición interna

Los modelos también pueden contener objetos duplicados, elementos superpuestos o geometrías repetidas. Estos errores pueden distorsionar cantidades, exportaciones, análisis y coordinación.

La ocurrencia puede surgir dentro de la propia disciplina, no solo entre disciplinas. Por eso, la auditoría debe incluir pruebas internas cuando exista riesgo de duplicidad, especialmente después de copias, vínculos, importaciones o consolidación de modelos.

Clash temporal o 4D

Cuando los modelos se asocian al cronograma, el análisis puede verificar interferencias en el tiempo. Algunos ejemplos son:

dos frentes ocupando la misma área simultáneamente;
equipo de izaje cruzando una zona de trabajo;
montaje previsto antes de liberar el acceso;
estructura temporal incompatible con una instalación definitiva;
ruta de transporte bloqueada por una actividad concurrente;
mantenimiento planificado durante la indisponibilidad de un sistema redundante.

El clash temporal no se limita a la geometría final. Analiza estados intermedios, métodos, equipos temporales y secuencia de implantación.

La verificación por reglas no siempre es Clash Detection

No toda comprobación automatizada es una colisión. Las herramientas pueden verificar parámetros, propiedades, clasificación, dimensiones, pendiente, accesibilidad, completitud de datos o cumplimiento de requisitos. Estos análisis son complementarios, pero deben identificarse correctamente.

Es importante separar:

Verificación	Pregunta principal	Ejemplo
Hard clash	¿dos elementos ocupan el mismo espacio?	la bandeja portacables atraviesa una viga
Soft clash	¿se respetó la distancia mínima?	panel sin área de mantenimiento
Duplicidad	¿existen objetos repetidos?	dos equipos en el mismo punto
Regla de información	¿las propiedades y datos son correctos?	equipo sin código o potencia
Verificación funcional	¿el sistema cumple el requisito?	¿la cámara posee cobertura adecuada?
Compatibilización	¿las disciplinas y decisiones están coordinadas?	¿alimentación, red, soporte y acceso están integrados?

Clash Detection no es compatibilización

La Compatibilización de Proyectos en BIM utiliza la detección de interferencias como una de sus herramientas, pero tiene un alcance más amplio. Trata interfaces físicas, funcionales, documentales, normativas, constructivas y operativas.

Clash Detection puede indicar que una bandeja portacables atraviesa un conducto. No decide automáticamente:

qué disciplina debe modificar la ruta;
qué sistema tiene prioridad técnica;
si existe capacidad en otro camino;
si el cambio afecta carga, caída de tensión o longitud;
si la nueva ruta respeta mantenimiento y segregación;
si la modificación altera cantidades, presupuesto o plazo;
qué documentos deben revisarse;
quién aprueba la solución final.

Estas decisiones pertenecen a la coordinación y compatibilización. Del mismo modo, el Design Review en Proyectos de Ingeniería analiza requisitos, cálculos, documentos, riesgos y madurez, yendo más allá de la geometría.

Detectar colisiones no significa compatibilizar el proyecto. El software localiza ocurrencias geométricas; el equipo de ingeniería debe decidir prioridades, responsabilidades, impactos y documentos afectados para transformar cada resultado en una solución coordinada.

Conozca el servicio de Compatibilización e Integración de Proyectos

Por qué la cantidad bruta de clashes puede engañar

Un modelo federado puede devolver cientos o miles de colisiones. Ese número, por sí solo, no representa la calidad del proyecto ni la cantidad real de problemas.

Una única causa puede generar decenas de registros. Un conducto que atraviesa una secuencia de elementos puede aparecer como varias colisiones. Los objetos compuestos pueden producir una ocurrencia por cada componente. Las geometrías simplificadas, tolerancias inadecuadas y elementos de referencia también amplían artificialmente la lista.

Falsos positivos

Los falsos positivos son resultados que cumplen matemáticamente la regla, pero no configuran un problema técnico. Algunos ejemplos son:

conexión prevista entre tubería y equipo;
conducto eléctrico empotrado en pared;
soporte asociado al elemento soportado;
aislamiento modelado sobre la propia tubería;
abertura estructural creada para el paso;
superposición intencional en un elemento de acabado;
geometrías de reserva o auxiliares de construcción.

El equipo debe establecer filtros y criterios de exclusión sin ocultar problemas reales.

Resultados repetidos

Las ocurrencias próximas pueden representar la misma causa. Agrupar por ambiente, sistema, elemento principal, disciplina, zona o decisión reduce ruido y facilita la asignación.

El agrupamiento no debe borrar la trazabilidad. La ocurrencia consolidada debe preservar qué elementos, ubicaciones y resultados fueron abarcados.

Tolerancia inadecuada

Una tolerancia cero puede generar conflictos derivados de precisión numérica, superficies coincidentes o pequeños desvíos sin relevancia constructiva. Una tolerancia excesiva puede ocultar interferencias importantes.

La configuración debe considerar:

unidad y precisión del modelo;
fase del proyecto;
disciplina;
método constructivo;
tamaño de los elementos;
holguras necesarias;
margen de instalación;
nivel de información disponible.

Modelo inmaduro o inadecuado

Clash Detection no corrige un modelo incompleto, desactualizado o mal coordinado. Si no se modelaron elementos críticos, no habrá colisión que detectar. Si la geometría es meramente simbólica, el resultado puede ser engañoso.

Las ausencias frecuentes incluyen soportes, accesorios, zonas de acceso, aberturas, aislamiento, pendiente, equipos temporales, envolventes de mantenimiento y elementos existentes.

El indicador correcto no es solo “clashes restantes”

Indicadores más útiles incluyen:

ocurrencias críticas abiertas;
tasa de cierre por ciclo;
reincidencia después de la corrección;
tiempo medio de respuesta;
ocurrencias por disciplina e interfaz;
porcentaje de falsos positivos;
conflictos aceptados con justificación;
problemas descubiertos en campo que deberían haberse detectado;
estabilidad de los modelos entre ciclos.

Cómo preparar los modelos para Clash Detection

Ejecutar pruebas antes de auditar los modelos suele generar resultados poco confiables. La preparación debe asegurar que los archivos puedan federarse, compararse y rastrearse.

Definir el alcance de la coordinación

El plan debe indicar:

disciplinas participantes;
áreas, plantas y zonas;
versiones y fechas de corte;
formatos de intercambio;
elementos incluidos y excluidos;
nivel de información necesario;
tolerancias;
prioridades de sistema;
responsables;
ciclos de análisis;
criterios de cierre.

No todos los elementos deben compararse con todos. La matriz de pruebas debe reflejar interfaces reales.

Verificar coordenadas y referencias

Los modelos deben compartir origen, orientación, niveles, plantas, unidades y sistema de coordenadas. Pequeñas desalineaciones pueden generar colisiones generalizadas u ocultar conflictos.

La auditoría debe verificar:

punto base y origen;
norte y rotación;
cotas y niveles;
unidades;
georreferenciación, cuando corresponda;
posición de vínculos;
transformación de archivos importados;
coherencia entre modelo, levantamiento y realidad.

Controlar versiones

Una federación con revisiones diferentes produce decisiones sobre configuraciones inexistentes. Cada archivo debe tener código, disciplina, revisión, fecha, estado y responsable.

Los modelos liberados para coordinación deben separarse de los archivos de trabajo. El proceso debe impedir que una prueba combine arquitectura actualizada con estructura antigua o instalaciones todavía no emitidas.

Verificar integridad y calidad

Antes de las pruebas, conviene analizar:

elementos duplicados;
geometrías corruptas;
objetos fuera del área del proyecto;
categorías incorrectas;
propiedades ausentes;
elementos excesivamente detallados;
vínculos rotos;
objetos no clasificados;
nombres y códigos inconsistentes;
elementos temporales no identificados.

Definir el nivel de información necesario

Modelar todo con el máximo detalle no es un requisito para una buena coordinación. El modelo debe contener información suficiente para la decisión correspondiente a la etapa.

En Proyecto Conceptual, pueden ser suficientes volúmenes, espacios y rutas principales. En Proyecto Básico, deben aparecer equipos, shafts, recorridos e interfaces críticas. En Proyecto Ejecutivo, se espera geometría e información compatibles con adquisición, fabricación, instalación y mantenimiento.

El detalle insuficiente oculta conflictos. El detalle excesivo aumenta procesamiento, ruido y costo sin un beneficio proporcional.

Preparar conjuntos de selección

Las pruebas robustas deben utilizar conjuntos basados en propiedades, clasificaciones y sistemas, evitando selecciones manuales frágiles.

Ejemplos:

todas las vigas estructurales;
conductos por encima de una sección determinada;
bandejas portacables de energía;
tuberías de protección contra incendios;
equipos que requieren acceso frontal;
puertas de paneles;
cables o bandejas de telecomunicaciones;
elementos por planta o zona.

Los conjuntos reutilizables facilitan la repetición de las pruebas en nuevas revisiones.

La calidad del resultado comienza antes de ejecutar la prueba. Coordenadas, revisiones, clasificación, nivel de información y conjuntos de selección deben ser consistentes; de lo contrario, el software solo automatiza los problemas de los modelos recibidos.

Profundice en el proceso de Compatibilización de Proyectos en BIM

Cómo montar una matriz de Clash Detection

La matriz define qué conjuntos se compararán, por qué existe la prueba, qué tolerancia debe utilizarse y quién responde por la interfaz.

Prueba	Conjunto A	Conjunto B	Tipo	Objetivo
CD-01	estructura	conductos de climatización	hard	evitar pasos no previstos
CD-02	estructura	bandejas portacables	hard	verificar rutas y aberturas
CD-03	hidráulica	eléctrica	hard	eliminar cruces incompatibles
CD-04	paneles eléctricos	envolvente frontal	soft	garantizar operación y mantenimiento
CD-05	luminarias	sprinklers	soft	preservar instalación y desempeño
CD-06	puertas	equipos y mobiliario	soft	verificar apertura y circulación
CD-07	bandejas de telecomunicaciones	potencia	soft	verificar la segregación definida
CD-08	equipos	rutas de retirada	soft	garantizar futura sustitución
CD-09	modelos disciplinares	elementos duplicados	duplicate	controlar superposiciones
CD-10	frentes de obra	áreas y equipos temporales	temporal	evitar conflicto de secuencia

Priorizar interfaces críticas

La matriz no debe comenzar con todas las combinaciones posibles. Priorice interfaces que puedan afectar:

seguridad;
estructura;
continuidad operativa;
sistemas críticos;
espacios difíciles de modificar;
equipos de largo plazo de suministro;
rutas principales;
mantenimiento;
hitos de procurement;
liberación de frentes.

Definir tolerancias por finalidad

Una misma tolerancia no sirve para todas las pruebas. El valor debe considerar dimensión, riesgo y capacidad de ajuste en campo.

Puede haber:

tolerancia geométrica de detección;
holgura mínima de instalación;
envolvente de mantenimiento;
zona de seguridad;
distancia de segregación;
reserva para expansión;
margen de fabricación y montaje.

La matriz debe registrar la fuente del criterio.

Evitar pruebas sin responsable

Cada prueba debe tener un responsable técnico. La responsabilidad puede ser de la coordinación, de una disciplina líder o del responsable de la interfaz. Sin responsable, la ocurrencia permanece únicamente como dato del software.

Proceso de Clash Detection paso a paso

1. Definir objetivo y criterio de decisión

El ciclo debe comenzar con una pregunta concreta. Ejemplos:

liberar shafts y salas técnicas;
validar rutas principales;
congelar aberturas estructurales;
liberar el modelo para presupuesto;
preparar el Proyecto Ejecutivo;
revisar documentación de proveedor;
confirmar la condición para iniciar la instalación.

La finalidad determina modelos, pruebas, tolerancias y severidad.

2. Recibir y auditar los modelos

El equipo verifica versiones, coordenadas, integridad, clasificación, completitud y cumplimiento de los requisitos de intercambio. Los archivos inadecuados deben devolverse o registrarse con una limitación.

3. Federar los modelos

La federación reúne las disciplinas para un análisis conjunto. El proceso debe preservar autoría, códigos, revisiones y estructura de los archivos.

El modelo federado no sustituye a los modelos de autoría. Es un entorno de coordinación.

4. Configurar y ejecutar las pruebas

Las pruebas deben utilizar conjuntos definidos, reglas documentadas y tolerancias justificadas. Conviene registrar la versión de la matriz, fecha, herramienta, modelos analizados y responsable de la ejecución.

5. Realizar triage técnico

El triage elimina o clasifica:

falsos positivos;
ocurrencias aceptadas;
duplicidades;
registros de la misma causa;
problemas fuera del alcance;
conflictos críticos;
conflictos que dependen de una decisión.

Esta etapa no debe delegarse únicamente al operador de la herramienta. Exige conocimiento de las disciplinas y del proyecto.

6. Agrupar ocurrencias

Los agrupamientos pueden realizarse por:

ambiente;
planta;
shaft;
sistema;
elemento principal;
disciplina responsable;
causa común;
solución esperada;
frente de ejecución.

Un grupo debe representar una decisión técnica administrable.

7. Crear y asignar issues

Cada issue debe contener información suficiente para comprenderse sin depender de una reunión informal.

Campos recomendados:

Campo	Contenido
Identificador	código único
Prueba de origen	regla que generó la ocurrencia
Ubicación	planta, ambiente, eje o coordenada
Elementos	IDs y disciplinas involucradas
Viewpoint	visualización reproducible
Descripción	problema y efecto esperado
Severidad	crítica, alta, media o baja
Prioridad	orden de tratamiento
Responsable	autor de la corrección o decisión
Plazo	fecha de respuesta y cierre
Estado	nuevo, activo, respondido, aprobado, resuelto o cerrado
Evidencia	revisión o documento que demuestra la solución

El BIM Collaboration Format puede transportar issues entre herramientas sin transferir nuevamente todo el modelo.

8. Analizar la causa y decidir la solución

La respuesta no debe ser simplemente “mover el elemento”. Es necesario evaluar requisitos, jerarquía de los sistemas, capacidad, espacio, acceso, costo, plazo e impacto documental.

Los posibles tratamientos incluyen:

modificar la ruta;
cambiar la cota;
redimensionar el shaft;
crear una abertura;
revisar el equipo;
modificar el soporte;
coordinar la secuencia;
aceptar el conflicto con justificación;
modificar un requisito;
solicitar información adicional.

9. Actualizar los modelos de autoría

La corrección debe ocurrir en el modelo responsable. Modificar solo el modelo federado o marcar la ocurrencia como resuelta sin revisar la fuente rompe la trazabilidad.

Los documentos asociados también pueden necesitar revisión: planos, memorias, listas, cantidades, especificaciones, cálculos y cronogramas.

10. Volver a ejecutar las pruebas

En la nueva revisión, las pruebas se repiten. El equipo verifica si:

el conflicto desapareció;
la solución no creó un nuevo problema;
los documentos son coherentes;
la interfaz fue efectivamente cerrada;
la configuración analizada corresponde a la revisión emitida.

11. Cerrar con evidencia

Una ocurrencia debe cerrarse cuando la solución haya sido incorporada y verificada. Una respuesta textual sin la revisión correspondiente no es evidencia suficiente.

Los clashes aceptados deben registrar justificación, autoridad y condición. Un conflicto puede ser técnicamente aceptable, pero no debe simplemente desaparecer de la lista.

Una issue respondida no es una issue cerrada. El cierre exige revisión incorporada, prueba ejecutada nuevamente y evidencia verificada. Cuando la solución modifica requisitos, contratos, equipos o línea base, el cambio también debe controlarse formalmente.

Vea cómo el Design Review controla comentarios, evidencias y decisiones de avance

Cómo clasificar severidad, prioridad y estado

La severidad representa el impacto técnico. La prioridad representa el orden de tratamiento. Los conceptos no son idénticos.

Severidad	Caracterización	Efecto típico
Crítica	riesgo de seguridad, inviabilidad, conflicto estructural o bloqueo de un sistema esencial	impide el avance
Alta	modificación relevante de ruta, espacio, equipo o interfaz	exige una decisión antes del siguiente hito
Media	ajuste localizado con impacto controlable	corregir en el ciclo actual
Baja	pequeña inconsistencia sin efecto sistémico	puede tratarse en una revisión posterior
Observación	mejora o duda sin conflicto confirmado	evaluar y documentar

La prioridad puede aumentar cuando existe un ítem de largo plazo, un frente próximo a liberarse, un área de difícil acceso o una decisión que afecta varias disciplinas.

Estado recomendado

Un flujo puede utilizar:

nuevo: identificado en el ciclo actual;
activo: confirmado y a la espera de tratamiento;
en análisis: depende de una decisión o información;
respondido: el responsable presentó una disposición;
aprobado: solución aceptada para implementación;
resuelto: la prueba ya no encuentra la interferencia;
cerrado: evidencia y documentos fueron verificados;
aceptado: el conflicto permanece con justificación formal;
reabierto: la solución fue insuficiente o creó una nueva inconsistencia.

La herramienta puede utilizar otra nomenclatura. Lo importante es definir el significado y los criterios de transición.

BCF, CDE, ENGiOS y trazabilidad

BCF para comunicación de issues

El BCF permite registrar ubicación, elementos, visualización, comentarios y datos de una ocurrencia vinculada al modelo. Reduce la dependencia de capturas aisladas y hojas de cálculo desconectadas.

El formato no sustituye el proceso de gobernanza. El equipo todavía debe definir clasificación, responsables, plazos, estado, aprobaciones y reglas de cierre.

Entorno Común de Datos

El CDE organiza publicación, intercambio, revisión, aprobación e historial de los contenedores de información. Debe distinguir archivos de trabajo, compartidos, publicados y archivados según el proceso adoptado.

La federación debe utilizar modelos autorizados para coordinación. La presencia de un archivo en el repositorio no significa que esté liberado.

ENGiOS como capa de gobernanza

ENGiOS puede controlar documentos, revisiones, emisiones, responsables, comentarios, aprobaciones, entregables, evidencias e indicadores. En un flujo integrado, las ocurrencias del modelo pueden asociarse con documentos, decisiones, contratos e hitos del proyecto.

Esta capa es especialmente útil cuando el problema no termina en el modelo. Una interferencia puede exigir revisión de una memoria, aprobación del propietario, cambio contractual, adquisición diferente o actualización del As-Built.

NetBox como contexto de la infraestructura

En proyectos de redes y Data Centers, NetBox puede proporcionar datos de sites, racks, dispositivos, interfaces, circuitos, cables, energía y direccionamiento. No ejecuta Clash Detection, pero ayuda a validar si la solución coordinada es coherente con la infraestructura lógica y física existente.

Una ruta geométricamente libre puede estar asociada a un rack sin capacidad, un puerto inexistente, un circuito no disponible o una topología incompatible. La integración entre el modelo y una fuente de verdad mejora la calidad de la decisión.

El modelo no debe ser la única fuente de decisión. BCF y CDE organizan la comunicación, ENGiOS controla documentos y aprobaciones, y NetBox añade el contexto de la infraestructura instalada. La integración reduce decisiones basadas en archivos aislados.

Conozca ENGiOS para gobernanza técnica de proyectos y documentos

Ejemplos de Clash Detection en sistemas de ingeniería

Instalaciones eléctricas

Las pruebas pueden comparar bandejas portacables, escalerillas, busways, conductos, cuadros, luminarias y equipos con estructura, arquitectura, hidráulica y climatización.

Además de hard clashes, deben modelarse o verificarse envolventes para apertura de puertas, retirada de interruptores, ventilación, acceso frontal y lateral y segregación de circuitos.

Cableado estructurado y telecomunicaciones

Las rutas de telecomunicaciones pueden entrar en conflicto con potencia, climatización, tuberías, cielorrasos, estructura y sistemas contra incendios. La detección ayuda a verificar recorridos, cruces y ocupación espacial.

Por sí sola, no confirma la distancia máxima del enlace, capacidad del rack, radio de curvatura, desempeño, certificación o topología. Estos aspectos exigen Design Review y análisis específico.

CCTV

La geometría puede identificar una cámara insertada en la estructura, un soporte incompatible o una ruta de infraestructura conflictiva.

No detecta automáticamente cobertura, densidad de píxeles, iluminación, contraluz, oclusión dinámica, retención, ancho de banda o ciberseguridad. Una cámara sin colisiones puede estar técnicamente mal posicionada.

Control de acceso

Pueden evaluarse lectores, cerraduras, controladoras, cajas, conductos, puertas y envolventes de apertura.

La compatibilización debe incluir herrajes, emergencia, incendio, ruta de evacuación, alimentación, lógica e integración con otros sistemas.

SPDA y puesta a tierra

Captadores, conductores, bajantes, electrodos y conexiones pueden coordinarse con arquitectura, estructura, cubierta, instalaciones eléctricas y equipos.

La ausencia de clash no demuestra análisis de riesgo, distancia de separación, equipotencialización, continuidad ni selección de DPS.

Data Centers

Clash Detection es relevante para bandejas portacables, busways, conductos, tuberías, racks, contenciones, equipos, pisos, cielorrasos y rutas de mantenimiento.

En entornos críticos, deben considerarse redundancia, separación entre rutas, mantenimiento concurrente, expansión y sustitución. Dos rutas pueden no colisionar y aun así compartir el mismo riesgo físico.

Retrofit e instalaciones existentes

Los modelos pueden compararse con nubes de puntos o levantamientos existentes. Esto ayuda a detectar incompatibilidades entre el proyecto y la condición real.

La confiabilidad depende de la calidad del levantamiento, del registro de áreas ocultas y de la actualización de las modificaciones realizadas en campo.

Qué no puede garantizar Clash Detection

La herramienta no garantiza, por sí sola:

cumplimiento de requisitos funcionales;
conformidad normativa completa;
cálculo correcto;
capacidad del sistema;
desempeño;
selectividad o protección eléctrica;
cobertura de CCTV;
lógica de automatización;
ciberseguridad;
accesibilidad;
constructibilidad completa;
secuencia de implantación;
operación y mantenimiento;
compatibilidad contractual;
actualización de todos los documentos;
aceptación del propietario.

Estos temas deben integrarse con el Design Review, el análisis de Constructibilidad, la Ingeniería de Valor y la gobernanza de cambios.

Clash Detection en las etapas del proyecto

Proyecto Conceptual

El análisis puede utilizar volúmenes, zonas y rutas principales para evitar configuraciones inviables. El objetivo no es encontrar detalles, sino proteger espacios e interfaces críticas.

Proyecto Básico y FEED

Deben coordinarse disposiciones, shafts, salas, equipos principales, rutas, aberturas, accesos y requisitos de mantenimiento. Las interferencias estructurales y decisiones de gran impacto deben resolverse antes del detallado.

Proyecto Ejecutivo

Las pruebas se vuelven más específicas. Los modelos deben reflejar equipos, accesorios, conexiones, soportes, holguras, aberturas, niveles e interfaces necesarias para la ejecución.

Un modelo sin clashes no debe considerarse automáticamente “liberado para construcción”. La liberación también depende de documentos, cálculos, aprobaciones, procurement y criterios contractuales.

Procurement y documentos de proveedores

Los modelos y planos de proveedores pueden modificar dimensiones, pesos, accesos, puntos de conexión y requisitos. La coordinación debe incorporar estos datos antes de la fabricación o instalación.

Ejecución y comisionamiento

Los cambios de campo deben regresar al proceso. De lo contrario, el modelo coordinado deja de representar la instalación real.

La actualización final debe alimentar la documentación As-Built, la operación, el mantenimiento y la gestión de activos.

Un modelo sin clashes no equivale a un proyecto liberado. La decisión de avanzar debe considerar cálculos, documentos, requisitos, procurement, constructibilidad, riesgos y condicionantes, además de la situación de las interferencias geométricas.

Entienda cómo Owner’s Engineering apoya la revisión, coordinación y aceptación

Entregables de un proceso de Clash Detection

El alcance puede incluir:

plan de coordinación;
requisitos de información;
lista de modelos y revisiones;
informe de auditoría de los modelos;
modelo federado;
matriz de pruebas;
reglas y tolerancias;
registro de ocurrencias;
archivos BCF;
viewpoints e imágenes;
informes por disciplina, área y severidad;
actas de coordinación;
matriz de responsabilidades;
dashboard de pendientes;
informe de cierre por ciclo;
lista de conflictos aceptados;
dictamen de preparación para el siguiente hito.

El entregable no debe ser únicamente una hoja de cálculo con miles de filas. Debe apoyar decisiones y demostrar qué fue analizado, corregido, aceptado y qué permanece abierto.

Indicadores para acompañar la coordinación

Indicadores posibles:

Indicador	Finalidad
ocurrencias nuevas por ciclo	medir estabilidad de los modelos
ocurrencias críticas abiertas	controlar riesgo de avance
tasa de cierre	acompañar respuesta de las disciplinas
tiempo medio de resolución	identificar cuellos de botella
reincidencia	evaluar calidad de las correcciones
falsos positivos	revisar configuración de las pruebas
issues sin responsable	verificar gobernanza
conflictos aceptados	controlar excepciones
ocurrencias por interfaz	localizar áreas de mayor riesgo
problemas descubiertos en campo	evaluar eficacia del proceso

Las metas puramente cuantitativas pueden incentivar cierres indebidos. La calidad de la solución debe prevalecer sobre la reducción artificial del número de registros.

Errores frecuentes

ejecutar pruebas antes de auditar los modelos;
utilizar coordenadas inconsistentes;
comparar revisiones diferentes;
configurar todas las disciplinas contra todas;
aplicar una única tolerancia;
considerar todo resultado un problema real;
eliminar falsos positivos sin registrar una regla de exclusión;
no agrupar ocurrencias repetidas;
asignar issues sin explicar la decisión necesaria;
tratar el clash como responsabilidad exclusiva del BIM Manager;
cerrar una ocurrencia con una respuesta textual;
corregir únicamente en el modelo federado;
no revisar planos y memorias asociados;
ignorar envolventes de mantenimiento;
limitar el análisis a hard clashes;
considerar un modelo sin clashes como proyecto aprobado;
no incorporar datos de proveedores;
no actualizar el As-Built.

Checklist para liberar un ciclo de Clash Detection

[ ] objetivo e hito de decisión están definidos;
[ ] modelos y revisiones fueron identificados;
[ ] coordenadas, unidades y niveles fueron auditados;
[ ] nivel de información es adecuado a la etapa;
[ ] matriz de pruebas fue aprobada;
[ ] tolerancias tienen justificación;
[ ] conjuntos de selección son reproducibles;
[ ] falsos positivos fueron tratados mediante reglas;
[ ] ocurrencias repetidas fueron agrupadas;
[ ] issues tienen responsable y plazo;
[ ] conflictos críticos fueron resueltos o condicionados;
[ ] correcciones fueron incorporadas a los modelos de autoría;
[ ] documentos afectados fueron actualizados;
[ ] pruebas fueron ejecutadas nuevamente;
[ ] evidencias fueron verificadas;
[ ] conflictos aceptados tienen justificación;
[ ] informe de cierre fue emitido;
[ ] modelos liberados corresponden a las revisiones analizadas.

Clash Detection es una herramienta poderosa para anticipar interferencias, pero su resultado depende de la calidad de los modelos, de la configuración de las pruebas y de la gobernanza aplicada a las ocurrencias. Cuando se integra con la compatibilización, el Design Review, la constructibilidad y el control de cambios, deja de ser una simple contabilización de colisiones y pasa a apoyar decisiones técnicas confiables a lo largo del proyecto.

Referencias técnicas

[1] AUTODESK. Visión general de la herramienta Clash Detective. Autodesk Help.

[2] BUILDINGSMART INTERNATIONAL. BIM Collaboration Format (BCF).

[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Information management using building information modelling — Concepts and principles.

[4] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650 — Organización y digitalización de información sobre edificaciones y obras de ingeniería, incluida la modelación de información de la construcción.

[5] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 7817-1:2024 — Building information modelling — Level of information need — Part 1: Concepts and principles.

Preguntas frecuentes

¿Qué es Clash Detection?

Es el análisis automatizado o semiautomatizado de modelos tridimensionales para identificar colisiones, superposiciones, violaciones de separación y otras interferencias definidas mediante reglas.

¿Clash Detection es lo mismo que compatibilización de proyectos?

No. Clash Detection identifica ocurrencias geométricas según reglas configuradas. La compatibilización interpreta los resultados, coordina disciplinas, resuelve interfaces y actualiza documentos y decisiones.

¿Cuáles son los principales tipos de clash?

Los principales son hard clash, cuando las geometrías se intersectan; soft clash, cuando se viola una separación mínima; duplicidades; y clashes temporales asociados a la secuencia de implantación.

¿Un modelo sin clashes está aprobado para ejecución?

No. La ausencia de colisiones no demuestra requisitos, cálculos, desempeño, conformidad normativa, constructibilidad, documentación ni aceptación del propietario.

¿Qué es un falso positivo en Clash Detection?

Es una ocurrencia que cumple matemáticamente la regla, pero no representa un problema técnico, como una conexión prevista, un elemento empotrado o una superposición intencional.

¿Cómo definir la tolerancia de una prueba?

La tolerancia debe considerar finalidad, etapa, disciplina, método constructivo, precisión del modelo, holguras de instalación, mantenimiento, seguridad y requisitos aplicables.

¿Para qué sirve BCF?

BCF permite intercambiar issues vinculadas al modelo, incluidos elementos, ubicación, viewpoints, comentarios, responsables y estado, sin transferir nuevamente todo el modelo BIM.

¿Quién debe resolver los clashes?

La coordinación administra el proceso, pero la solución depende de los proyectistas y responsables de las disciplinas e interfaces. El BIM Manager o el operador de la herramienta no debe decidir por sí solo modificaciones técnicas.