Clash detection: de la interferencia a la incidencia cerrada

El clash detection, o detección de interferencias, es la comparación automática de modelos BIM de distintas disciplinas para encontrar elementos que chocan o que no respetan la distancia mínima entre sí. El resultado de una corrida es una lista de pares de elementos con sus coordenadas. Esa lista no resuelve nada. La interferencia se resuelve cuando alguien la agrupa, la convierte en una incidencia con responsable y fecha, corrige el modelo y otra persona verifica el cierre.

Tipos de interferencia

La detección de interferencias distingue tres tipos.

Las duras son las más fáciles de detectar y las que llenan los reportes. Las blandas dependen de que el equipo defina las holguras de cada sistema. Las de flujo de trabajo requieren que el modelo esté vinculado al cronograma.

Por qué un reporte de clashes no resuelve nada

Una corrida entre instalaciones y estructura puede devolver cientos o miles de resultados. Enviar ese reporte por correo a los proyectistas tiene tres problemas:

• Mezcla lo grave con lo irrelevante. Una tubería principal contra una placa aparece junto a un conduit que roza un tabique.
• Repite el mismo problema muchas veces. Un ducto que cruza veinte vigas genera veinte filas y es una sola decisión.
• No tiene dueño. Un clash describe un hecho geométrico. No dice quién debe mover qué ni para cuándo.

Un clash es un dato. Una incidencia es un compromiso. Todo el trabajo de coordinación está en pasar de uno a otro.

Agrupar y priorizar

Antes de asignar nada, la persona que coordina depura la corrida.

Descarta. Interferencias por debajo de la tolerancia acordada, pares de elementos que el equipo definió como aceptables y resultados ya registrados en la corrida anterior.

Agrupa. Por elemento común (el mismo ducto contra varias vigas), por zona o nivel y por causa de fondo. Si todas las bajadas sanitarias chocan con la misma viga de borde, el problema es el trazo del montante y no doce tuberías.

Prioriza. Tres criterios ayudan:

• Fecha de construcción. Primero lo que se ejecuta antes.
• Costo de corregir en obra. Una perforación en una viga postensada no se improvisa.
• Quién cede. Suele moverse el sistema más flexible. Una regla habitual, que cada proyecto debe acordar: manda la estructura, luego las tuberías por gravedad, los ductos de gran sección, las tuberías a presión y, al final, bandejas y conduit.

Ejemplo de depuración

Un caso ilustrativo. La corrida de instalaciones mecánicas contra estructura del nivel 3 devuelve 420 resultados. La coordinadora descarta 150 por estar bajo la tolerancia o entre elementos aceptados y 90 que ya estaban registrados. Quedan 180. Al agruparlos por elemento y por causa, se convierten en 14 incidencias. A la reunión llegan 14 temas con responsable propuesto, no 420 filas.

De la interferencia a la incidencia

Cada grupo se registra como una incidencia con estos datos:

• Título que describe el problema. «Ducto de extracción cruza vigas del eje 4, nivel 3».
• Ubicación. Nivel, eje y un punto de vista guardado del modelo.
• Elementos implicados. Los que chocan, con su disciplina.
• Un responsable. Una sola persona o empresa. Si son dos, nadie se mueve primero.
• Fecha límite. Atada a la próxima entrega de modelos o a la fecha en que se construye esa zona.
• Prioridad y, si existe, la solución propuesta.

Si resolver la interferencia exige un criterio del proyectista, la incidencia se eleva a un RFI.

BCF: mover la incidencia entre herramientas

El modelador trabaja en su programa de autoría. La coordinadora, en un visor de revisión. Si la incidencia viaja como una captura de pantalla en un PDF, cada uno tiene que buscar el punto a mano.

BCF, el BIM Collaboration Format de buildingSMART, resuelve ese traslado. Un archivo BCF no contiene el modelo. Contiene la incidencia: su título, estado y comentarios, el punto de vista de la cámara y los identificadores de los elementos implicados. Quien lo abre en su herramienta aterriza en el mismo encuadre, con los mismos elementos seleccionados. Para que funcione, los modelos deben compartir identificadores estables, lo que en la práctica significa intercambiar en IFC.

La reunión de coordinación

La reunión no es para detectar interferencias. Eso se hace antes. Es para decidir lo que no se pudo resolver entre dos personas. En una sesión ICE bien preparada:

1. Se revisan primero las incidencias vencidas de la reunión anterior.
2. Se abren en el modelo solo las que requieren una decisión entre disciplinas.
3. Cada decisión queda escrita en la incidencia, con responsable y fecha.
4. Lo que no se decide sale con un dueño para la consulta pendiente.

Medir el cierre

El número bruto de clashes sube y baja con las reglas de la corrida, así que dice poco. Indicadores más útiles:

• Incidencias abiertas y cerradas por ciclo. Si se abren más de las que se cierran, la coordinación va detrás del diseño.
• Antigüedad de las abiertas. Cuántas llevan más de dos ciclos sin moverse.
• Reaperturas. Una incidencia que vuelve indica que se cerró sin verificar.
• Interferencias nuevas frente a persistentes. Las persistentes son correcciones que no se hicieron.

Una incidencia se cierra cuando una nueva corrida sobre el modelo actualizado ya no la muestra. No cuando el responsable dice que lo corrigió.

Errores frecuentes

• Correr la detección sobre modelos desactualizados. Se discuten conflictos que ya no existen.
• No acordar tolerancias. La mitad del reporte es ruido.
• Enviar el reporte completo por correo. Nadie lo lee entero y nadie se siente responsable.
• Asignar a una disciplina y no a una persona. «Instalaciones» no responde mensajes.
• Cerrar sin verificar. El conflicto reaparece en obra, donde corregirlo cuesta más.

Cómo se hace en Wayki

Wayki es el sistema de inteligencia operativa para la ejecución de proyectos de construcción. En coordinación, registra las interferencias y vigila que no queden sin dueño.

Cómo se registra. La detección se ejecuta dentro del módulo de auditoría BIM sobre los modelos de un cluster, que es el modelo federado del proyecto. Eliges dos selecciones a comparar, por modelo completo o por nivel y categoría, el tipo de análisis (interferencia dura o distancia mínima) y la tolerancia en metros. Los resultados muestran la severidad, los dos elementos con su categoría y nivel, la distancia y un estado de revisión. Al seleccionar una fila, el visor resalta la interferencia. Desde ahí se crea una incidencia anclada a ese punto, con responsable, fecha límite, comentarios y cierre con historial. Los modelos llegan desde los complementos de Revit y Navisworks o como IFC.

Qué hace Wayki con eso. Cuando una corrida termina con un número significativo de interferencias, el Centro de riesgos abre un hallazgo para ese par de modelos. Se actualiza con cada nueva corrida y se resuelve solo cuando la última sale limpia. Las incidencias estancadas y los acuerdos de reunión vencidos aparecen ahí también. En la ficha de cada incidencia, el contexto de decisión muestra las actividades del cronograma que afecta y lo que falta para decidir. Las severidades salen de reglas determinísticas, no de un modelo de IA.

Puedes ver el flujo completo en la solución de coordinación BIM o solicitar una demo con tus propios modelos.

Preguntas frecuentes

¿Qué diferencia hay entre un clash duro y uno blando?

En un clash duro dos elementos ocupan el mismo espacio, como un ducto que atraviesa una viga. En un clash blando no se tocan, pero uno invade la distancia mínima que el otro necesita para aislamiento, montaje, mantenimiento o seguridad.

¿Cada cuánto conviene correr la detección de interferencias?

Cada vez que las disciplinas publican una nueva versión de sus modelos y antes de cada reunión de coordinación. Correrla más seguido sobre modelos que no cambiaron solo repite resultados. Correrla menos acumula conflictos que luego cuestan más.

¿Qué es BCF y para qué sirve?

BCF (BIM Collaboration Format) es un formato abierto de buildingSMART para intercambiar incidencias entre programas BIM. Lleva el punto de vista, los elementos implicados, los comentarios y el estado, sin copiar el modelo. Sirve para que cada especialista abra la incidencia en su propia herramienta.

¿Cuántos clashes son aceptables en un modelo?

El número bruto no dice mucho, porque depende de las reglas y tolerancias de cada corrida. Lo que importa es que no quede ninguna interferencia sin resolver en lo que se va a construir a continuación y que las incidencias abiertas tengan responsable y fecha.