En este caso práctico se muestra cómo se reconstruyó en TeKton3D una instalación completa de extinción por agua a partir de un IFC exportado desde ROwin. A lo largo del artículo se explica cómo Claude Code con el modelo Opus 4.8, ejecutado desde Claude Desktop y conectado mediante el MCP de TeKton3D, analizó el archivo, desarrolló un parser adaptado a su estructura, creó tuberías y equipos, reconstruyó las conexiones de la red y verificó su continuidad hidráulica. También se detallan los datos que deben completarse posteriormente en TK-EXA para disponer de un modelo plenamente preparado para el cálculo.
El punto de partida fue un archivo IFC exportado desde ROwin que contenía una instalación completa de extinción por agua (Fig. 01). El objetivo consistía en trasladarla a TeKton3D manteniendo la posición de los elementos y sus principales parámetros geométricos y técnicos, hasta obtener una red coherente y preparada para completar su definición de cálculo.
Para realizar el proceso se utilizó Claude Code desde Claude Desktop, conectado al MCP de TeKton3D. El agente analizó el IFC, desarrolló el parser necesario para interpretar su contenido, preparó los datos y creó los elementos mediante la API, mientras que las operaciones que dependen de la interfaz gráfica —como la sincronización de plantas o el recálculo— se ejecutaron directamente en TeKton3D. El caso permite valorar de forma práctica el alcance de esta integración para automatizar tareas de intercambio y reconstrucción de modelos BIM-MEP.
Definición de niveles del edificio
El IFC declaraba formalmente una sola planta, ya que ROwin no genera una estructura completa de niveles de edificio. Sin embargo, la geometría de los rociadores mostraba dos agrupaciones claramente diferenciadas, situadas aproximadamente a 3,8 m y 7,6 m. A partir de esta información se establecieron los dos niveles necesarios en el proyecto de TeKton3D.
El MCP permite consultar la tabla de plantas del proyecto, mientras que la creación y sincronización de nuevos niveles se realiza actualmente desde la interfaz de TeKton3D. Para completar este paso se crearon espacios de referencia y se utilizó el comando Herramientas → Sincronizar plantas con espacios. De este modo, la automatización se combinó con las funciones propias de edición del programa.
Creación de la instalación
Claude Code desarrolló para este caso un parser específico que leyó el IFC y extrajo, en coordenadas globales, los ejes y diámetros de las tuberías —acero UNE-EN 10255, con seis calibres entre 1″ y 4″—, así como la posición y orientación de los distintos equipos. Las tuberías se generaron con el diámetro y el material indicados en el archivo, y los equipos se insertaron como objetos de catálogo en sus coordenadas correspondientes. La creación se realizó por lotes y se validó previamente con una muestra reducida.
Resolución de las conexiones
Durante la comprobación de la red se observó que algunos rociadores no quedaban relacionados con las tuberías. El origen estaba en la representación exportada por ROwin: al generarse a partir de planos 2D y datos de proyecto, algunos elementos incorporaban pequeñas separaciones geométricas con respecto al ramal. En el caso de los rociadores, el IFC incluía un desfase vertical de aproximadamente 15 mm asociado a su colocación.
En TeKton3D, la conectividad se establece cuando una tubería alcanza uno de los puntos de conexión definidos en el objeto. Por ello, al reconstruir la instalación mediante la API es necesario reproducir también los tramos que enlazan cada equipo con la red.
En las BIE se identificó una situación distinta. El montante que conecta cada armario con el colector estaba presente en el IFC con geometría de tubería, perfil circular, longitud y diámetro definidos, pero clasificado como IfcBuildingElementProxy en lugar de IfcPipeSegment. Para conservar esta información, el parser no se limitó a la clase IFC declarada y analizó también la geometría de los elementos genéricos.
A partir de estos datos se crearon los tramos de enlace necesarios: conexiones de 15 mm para los rociadores y los montantes completos para las BIE. El mismo criterio se aplicó al grupo de bombeo y al puesto de control, asegurando que sus conectores quedaran integrados en la red.
Verificación de la conectividad
La red se representó como un grafo formado por nudos y tramos. Sobre esta estructura se aplicó un algoritmo union-find para comprobar que existía una única componente conexa, que no quedaban objetos sin relación y que no aparecían extremos abiertos distintos de los terminales previstos.
La comprobación permitió localizar una separación entre la red de rociadores y el conjunto formado por el bombeo y las BIE. El puesto de control, encargado de unir ambos sectores, no estaba relacionado inicialmente con las tuberías de sus dos conectores. Tras recrear esos enlaces, toda la instalación quedó integrada en un único circuito: bombeo → puesto de control → red de rociadores.
Representación tridimensional
Una vez verificada la conectividad, los símbolos provisionales se sustituyeron por los bloques 3D correspondientes de TeKton3D: rociadores colgantes, armarios de BIE (Fig. 05), grupo de bombeo y puesto de control. En este último caso fue necesario adaptar los tramos adyacentes a la separación real entre sus conectores. La comprobación geométrica confirmó además que el cambio de símbolo mantiene la posición de conexión del objeto.
Información necesaria para el cálculo
La reconstrucción geométrica y topológica no completa por sí sola todos los datos necesarios para el cálculo en TK-EXA. Determinada información no forma parte del IFC de origen y debe definirse posteriormente en el proyecto de TeKton3D.
Entre estos datos se encuentran las zonas, las hipótesis de cálculo y la selección concreta de series comerciales de tubería cuando el IFC solo aporta el diámetro. Al no estar presentes en el archivo, deben incorporarse en TK-EXA antes de ejecutar el cálculo.
También existe una diferencia entre ambos modelos de datos. En ROwin, el grupo de bombeo se representa como un único objeto; en TK-EXA, el cálculo requiere diferenciar el equipo de bombeo y la fuente de agua. Por tanto, la fuente debe añadirse como un elemento independiente cuando no figure expresamente en el IFC.
La definición completa de espacios en el capítulo Edificio constituye igualmente un requisito previo. Los espacios de referencia utilizados para sincronizar las plantas permiten establecer los niveles, pero las zonas y las hipótesis de cálculo dependen de una modelización adecuada del edificio antes de efectuar el recálculo de la instalación.
Valoración del procedimiento
El caso muestra que la conexión de Claude Code con TeKton3D mediante MCP resulta especialmente útil para automatizar operaciones como desarrollar el parser adaptado al IFC de origen, interpretar sus datos, transformar coordenadas, crear grandes conjuntos de elementos y verificar la conectividad de la red. La supervisión técnica continúa siendo necesaria para definir los criterios de ingeniería, completar los datos que no contiene el IFC y validar el modelo resultante.
El resultado es una instalación contra incendios reconstruida a partir del IFC, representada en 3D y con su continuidad hidráulica verificada, preparada para completar los datos de proyecto y efectuar el cálculo en TeKton3D.
Conclusiones
A partir del IFC de ROwin se generó en TK-EXA una instalación formada por 248 tuberías, 182 rociadores y 6 BIE, manteniendo sus posiciones y dimensiones principales. La red quedó organizada como un único circuito hidráulico verificado mediante análisis de grafos y con sus principales equipos representados mediante objetos 3D.
Para convertirla en un modelo plenamente calculable es necesario completar las zonas, las hipótesis de cálculo, la fuente de agua asociada al grupo de bombeo y la definición de espacios en el capítulo Edificio. Estas tareas corresponden a la configuración técnica del proyecto y no pueden deducirse automáticamente del IFC cuando el archivo no contiene esa información.
El procedimiento seguido puede resumirse en cinco etapas: analizar el IFC, transformar e inventariar los datos, crear los elementos en TeKton3D, reconstruir sus conexiones y verificar la topología de la red. Esta secuencia proporciona una base reproducible para abordar intercambios similares.
La adaptación a otros archivos IFC dependerá de la estructura y de las convenciones utilizadas por cada aplicación exportadora. Pueden variar los niveles, las denominaciones, las clases IFC y la forma de representar determinados elementos. Por ello, tanto el prompt como el parser generado por el agente para este caso deben considerarse una base adaptable, no una plantilla invariable.
Anexo — planteamiento utilizado
Para esta prueba se facilitó al agente una instrucción general con el objetivo, los criterios de análisis y las comprobaciones que debía realizar. El texto se adaptó durante el proceso a la estructura concreta del IFC exportado desde ROwin.
Marcas y denominaciones
Claude, Claude Code, Claude Desktop y Claude Opus son productos y denominaciones de Anthropic. El Model Context Protocol (MCP), creado originalmente por Anthropic, es actualmente un proyecto de código abierto integrado en la Agentic AI Foundation, bajo la Linux Foundation. TeKton3D, TK-EXA y ROwin son productos de iMventa Ingenieros. IFC™ y openBIM® son marcas de buildingSMART International.
Las restantes marcas, nombres comerciales y productos citados pertenecen a sus respectivos titulares. Su mención en este artículo tiene una finalidad exclusivamente descriptiva y no implica patrocinio, asociación ni colaboración comercial entre las entidades mencionadas.