后 BIM 世界。向数据和流程过渡，建筑行业是否需要语义、格式和互操作性
27 December 2024
Die Welt nach BIM. Braucht das Baugewerbe Semantik, Formate und Interoperabilität, wenn es um Daten und Prozesse geht?
7 January 2025
Con la llegada de los datos digitales en la década de 1990, la industria de la construcción comenzó a transformarse activamente. La tecnología informática se introdujo en los procesos de diseño, gestión y construcción, lo que dio lugar a la aparición de conceptos como CAD (Computer-Aided Design systems), PLM (Product Lifecycle Management) y, más tarde, BIM (Building Information Modeling).
Sin embargo, como cualquier innovación, no son el punto final del desarrollo. Conceptos como BIM se han convertido en un hito importante en la historia de la industria de la construcción, pero tarde o temprano darán paso a mejores herramientas y enfoques que responderán mejor a los desafíos del futuro.
Abrumado por la influencia de los proveedores de CAD y confundido por las complejidades de su propia implementación, el concepto BIM que surgió en 2002 puede que no llegue a cumplir treinta años, como una estrella de rock que brilló con fuerza pero se apagó rápidamente. La razón es simple: las demandas de los especialistas en datos están cambiando más rápido de lo que los proveedores de CAD pueden adaptarse a ellas.
Ante la falta de datos de calidad, los profesionales de la construcción exigen interoperabilidad entre plataformas y acceso a datos abiertos para facilitar su análisis y procesamiento. La falta de datos y su complejidad tienen un impacto negativo en todos los involucrados en el proceso de construcción: diseñadores, gerentes de proyecto, trabajadores de la construcción en la obra y, en última instancia, el cliente.
En lugar de un conjunto completo de datos para su funcionamiento, el cliente y el inversor reciben contenedores en formatos que requieren núcleos geométricos complejos, una comprensión de los esquemas de datos, documentación API actualizada anualmente y software CAD-BIM especializado para trabajar con los datos. Al mismo tiempo, gran parte de los datos de diseño permanecen sin utilizar.
Este enfoque está obsoleto y ya no satisface las demandas del entorno digital actual. El futuro dividirá a las empresas en dos tipos: las que utilizan los datos de manera eficaz y las que abandonan el mercado.
En este artículo, analizaremos el marco BIM existente, incluido el uso de formatos CAD (BIM), IFC y USD, y los enfoques alternativos y futuros para trabajar con datos y procesos, y responderemos preguntas clave que son de interés para los profesionales de datos en la industria de la construcción hoy:
- ¿Qué es BIM? ¿Marketing o innovación real para la industria de la construcción?
- Por qué los formatos CAD están acabando con la interoperabilidad y el concepto de BIM
- USD vs. IFC: ¿por qué los proveedores imponen nuevos formatos?
- Por qué los nuevos formatos de los proveedores CAD IFC y USD no resuelven problemas clave de interoperabilidad
- ¿Por qué los proveedores de CAD abandonarán los archivos y pasarán a datos granulares a partir de 2023?
- Por qué los formatos CAD paramétricos y la geometría BREP no son esenciales para la industria de la construcción
- Cómo Strabag y Züblin desafiaron a los proveedores de CAD y qué resultó de ello
- Por qué el uso de la semántica y las ontologías en la gestión de datos resulta insuficiente.
- Por qué las empresas de construcción se opondrán al uso de datos abiertos
- ¿Y cuáles son las herramientas del futuro para tratar los datos de los proyectos de construcción?
Muchas gracias por las valiosas discusiones y debates sobre las cuestiones planteadas porRasso Steinmann, Thomas Liebich, Ulf-Günter Krause, Bernd Müller-Jürries, Simón Dihlas, Michael Maass, queridos miembros de BuildingSMART, elComunidad OSArchy elChat sobre construcción basada en datosgrupo.
Contenido:
- BIM se trata de datos y procesos, pero ¿por qué el acrónimo?
- Cada usuario de datos CAD (BIM) atiende a diez consumidores de datos
- Cualquier programa CAD (BIM) es un compilador de datos que visualiza la geometría a través de un núcleo de geometría.
- CAD, IFC y núcleos geométricos: ¿quién manda?
- IFC es CAD dentro de CAD con una dependencia del núcleo de geometría y del SDK
- ¿Por qué los constructores necesitan geometría? Cuando las líneas se convierten en dinero
- Cálculos básicos en construcción o de líneas a volúmenes: Cómo el área y el volumen se convierten en números
- ¿Por qué necesitamos triángulos? Toda la verdad sobre la teselación en la construcción
- El intento de Zublin-Strabag de subordinar a los proveedores de CAD (BIM) a los intereses de la industria de la construcción
- El surgimiento de la semántica y la ontología en la industria de la construcción
- Semántica y ontología: ¿cómo hacer que los datos hablen?
- De gráficos a tablas: costes laborales en agrupación y filtrado
- A la sombra de ISO y buildingSMART: la guerra por el control del formato de datos
- ¿Por qué los constructores y los clientes necesitan controlar los datos?
- La uberización y los datos abiertos son una amenaza para el negocio de la construcción
- ¿BIM, openBIM, BIM Nivel 3 y noBIM existen realmente o son trucos de marketing?
- ¿Qué sigue? Formatos sencillos y herramientas fáciles de usar
- Surgimiento de LLM y ChatGPT en los procesos de datos del proyecto En lugar de la conclusión
1. BIM se trata de datos y procesos, pero ¿por qué el acrónimo?
El concepto de BIM (Building Information Modeling), resucitado en la industria de la construcción con la publicación de ADSKs BIMLibro blancoEn 2002, y complementado por el concepto de ingeniería mecánica de BOM (Bills of Materials), se originó a partir del enfoque paramétrico para crear y procesar datos de proyectos. El enfoque paramétrico para crear y procesar datos de diseño se implementó por primera vez en el sistema Pro/Engineer para diseño de ingeniería mecánica (MCAD).El sistema se convirtió en el prototipopara muchas soluciones CAD modernas, incluidas aquellas que se utilizan hoy en día en la industria de la construcción.
Fig. 1 Historia del surgimiento de productos BIM Revit, Solidworks, Autocad y Whitepaper
Cita deSamuel Geisberg, fundador de PTC, desarrollador del producto MCAD Pro/ENGINEER y mentor de Leonid Reitz, creador de Revit:
El objetivo es crear un sistema que sea lo suficientemente flexible como para animar al ingeniero a considerar fácilmente diferentes diseños. Y el coste de realizar cambios en el diseño debe ser lo más cercano a cero posible. El software CAD/CAM tradicional de la época limita de manera poco realista la realización de cambios económicos únicamente a la etapa inicial del proceso de diseño.
Ya a finales de la década de 1980, el objetivo eraeliminar las limitaciones de laLos programas CAD existentes en aquel momento tenían como objetivo principal reducir el trabajo necesario para realizar cambios en los parámetros de los elementos de diseño y permitir la actualización del modelo a partir de datos externos a los programas CAD. En este caso, el papel clave lo desempeñaba la parametrización de la tarea y la introducción automática de parámetros desde la base de datos para actualizar el modelo en el sistema CAD.
Después de que ADSK finalizara su compra de Revit (con el concepto de lista de materiales heredado de Pro/ENGINEER), los dos vicepresidentes de ADSK prepararon unLibro blancoque marcó la llegada del concepto BIM a la industria de la construcción en 2002.
Figura 2. Aparición del Libro Blanco BIM en 2002
En un sitio web con un libro blanco publicado sobre BIM, ADSK en realidad reprodujo los materiales de marketing del concepto BOM (Listas de materiales) de los productos Pro/ENGINEERusadoa principios de la década de 1990.
BIM se describe como la gestión de información de construcción, donde todas las actualizaciones y todos los cambios se llevan a cabo en una base de datos. De modo que, ya sea que se trate de esquemas, secciones o planos, todo está siempre coordinado, es coherente y está actualizado.
Casi todos los conceptos modernos para agregar y procesar parámetros en la construcción, como IFC, BIM, openBIM yConstrucción inteligente, han sido respaldadas en su creación y promovidas por proveedores de soluciones CAD. Sin embargo, muchas de estas ideas son prestadas de otras industrias o adquiridas de empresas emergentes. Por ejemplo, ADSK no creó Revit, el concepto BIM, AutoCAD Architecture, Navisworks, Civil 3D y Advanced Steel por sí sola, sino que adquirió estas soluciones de empresas emergentes.
Similarmente,Construcción inteligenteno creó el formato IFC ni el acrónimo openBIM®. IFC fueAdaptado por la Universidad Técnica de Munichdel formato de ingeniería mecánica STEP, y posteriormente renombradoporHOK creará la Alianza IAI, mientras que openBIM sólo se renovómarcado porConstrucción inteligentecomo marca a principios de la década de 2020 después de su registro inicialporVarios proveedores de CAD en 2012. El formato IFC-STEP, a su vez, se basa en IGES, creado en 1979 por un grupo de usuarios y proveedores de CAD con el apoyo del NIST y el Departamento de Defensa de los EE. UU. Los vínculos entre los desarrolladores y las ideas de los conceptos modernos se presentan enEl mapa de la “Historia de BIM”.
Figura 3. Mapa de conexiones de los principales equipos de desarrolladores de soluciones CAD (BIM)
La ingeniería mecánica, de donde provienen las herramientas y conceptos básicos, está dejando de trabajar con términos CAD, CAM y PLM para pasar a trabajar con gemelos digitales y procesos de gestión de datos de extremo a extremo. Los procesos de diseño, fabricación y operaciones no se ven a través de la lente de herramientas específicas (de empresas como PTC, Siemens y Dassault Systemes), sino a través de enfoques unificados de datos y procesos. En lugar de términos especializados como BOM, PLM o PDM, el concepto de gestión de datos, gestión de procesos yanálisis de datosEl término se utiliza cada vez más. No es solo en la ingeniería mecánica y en otras industrias donde se observa esta transición desde abreviaturas estrechas de proveedores de software a conceptos universales liderados por “datos” y “procesos”.
Los usuarios y desarrolladores de la industria de la construcción, al igual que sus contrapartes en otras industrias, inevitablemente se alejarán de la vaga terminología de los proveedores de software que ha dominado los últimos 20 años, centrándose en los aspectos clave de la digitalización: “datos” y “procesos”.
Figura 4. Los procesos de construcción y diseño están inextricablemente vinculados a los datos y procesos.
Sin acceso libre a datos estructurados de alta calidad, será imposible crear procesos eficientes y automatizarlos en el futuro. Por lo tanto, la primera prioridad será descubrir, organizar, unificar y organizar los datos, lo que creará la base para la automatización y optimización de los procesos comerciales.
Para comprender la complejidad y la confusión del concepto actual de gestión de datos y procesos CAD-BIM, analizaremos los aspectos básicos de la creación de la geometría y la metainformación que se utilizan en los datos de diseño. Esto responderá a la pregunta de por qué el uso, la automatización y la estandarización de los datos de diseño han seguido siendo un desafío durante los últimos 30 años.
2. Cada usuario de datos CAD (BIM) atiende a diez consumidores de datos
Si bien antes de principios de los años 2000 la proporción de datos almacenados en formato digital era extremadamente pequeña y prácticamente no se planteaban problemas relacionados con su utilización en otros sistemas, hoy la situación ha cambiado radicalmente gracias a la aparición de CAD (BIM), PLM, ERP, Excel y aplicaciones basadas en SQL. El número de sistemas que consumen datos se ha multiplicado por diez, lo que ha provocado una auténtica crisis para los directivos y especialistas que deben recibir, procesar y transmitir datos.
Figura 5. Esquema de integración de datos y procesos en el ecosistema de empresas constructoras
Desde principios de la década de 2000, la cantidad de empleados de oficina involucrados en el mantenimiento de varios sistemas de interfaz de usuario y bases de datos ha crecido exponencialmente, lo que resultó en un aumento dramático en la importancia del acceso y el uso compartido de datos. Como director ejecutivo de ADSKobservado en 2002, por cada ingeniero CAD ya a principios de la década de 2000 había al menos una docena de otros especialistas que necesitaban trabajar con datos creados en sistemas CAD (Cita):
Es necesario poder gestionar todos esos datos (CAD, nota del autor), almacenarlos digitalmente y vender software de gestión de procesos y ciclo de vida, porque por cada ingeniero que crea algo, hay diez personas que tienen que trabajar con los datos.
A principios de la década de 2020, el número de profesionales que trabajan con datos de programas CAD y BIM ha crecido exponencialmente, llegando a cientos de profesionales en grandes empresas, desde administradores de sistemas GIS, ERP y CAFM hasta capataces de obras.
Figura 6. Decenas de especialistas por ingeniero creando datos en programas CAD (BIM)
Todos estos usuarios y sus administradores de datos en la industria de la construcción se esfuerzan por lograr una compatibilidad total entre diferentes programas y plataformas, y más específicamente bases de datos y formatos de datos. Y aunque casi todos los sistemas y bases de datos en la industria de la construcción están abiertos a ingenieros y profesionales de TI, solo CAD (BIM) sigue siendo una base de datos cerrada con formatos propietarios. Estos puestos de avanzada cerrados de información de proyectos han afectado a docenas de otros departamentos y cientos de profesionales durante los últimos 30 años, creando una dependencia de acceso limitado a la información.
Las cuestiones de verdadera multiplataforma e interoperabilidad se enfrentan al problema fundamental de la naturaleza cerrada de los programas CAD y los complejos núcleos de geometría propietarios, las herramientas SDK de terceros y los diversos esquemas de datos que utilizan en formatos propietarios..
Figura 7. De todas las bases de datos, solo el acceso CAD (BIM) sigue sin estar disponible
¿Por qué necesitamos sistemas CAD (BIM) en la construcción? Su principal tarea es ayudar al diseñador a crear nuevos datos basados en los parámetros iniciales de las tareas del proyecto, que incluyen tanto la geometría de los elementos de diseño como la metainformación relacionada.Definición de Wikipedia:
El modelado de información de construcción (BIM) es un método para crear y gestionar representaciones digitales de las características físicas y funcionales de edificios y otros objetos.
La mayoría de los sistemas CAD (BIM) utilizan bases de datos cerradas y formatos de almacenamiento propietarios para crear y almacenar estas características y parámetros. Además, utilizan núcleos de geometría propietarios sofisticados que proporcionan visualización e interacción interactiva con la geometría del proyecto.
3. Cualquier programa CAD (BIM) es un compilador de datos que visualiza la geometría a través de un núcleo de geometría.
Cada programa CAD (BIM) utiliza su propio núcleo de geometría o depende de una solución patentada de terceros, lo que complica enormemente el intercambio de datos entre diferentes plataformas.
Cualquier programa CAD (BIM) es un compilador de datos geométricos que se muestran mediante un núcleo de geometría.
El mercado está dominado por núcleos de geometría como Siemens Parasolid, Dassault Systèmes CGM, PTC ProEngineer, ADSK ShapeManager y ASCON C3D. Los únicos núcleos de geometría de código abierto y gratuitos son OpenCascade y la biblioteca OCGL bajo licencia GPL.
Figura 8. Arquitectura del flujo de trabajo de los sistemas CAD/BIM: desde las bases de código hasta la visualización
En el caso de elementos geométricos simples, como líneas o planos, no existen problemas a la hora de dibujar geometrías con parámetros. Sin embargo, cuando se trabaja con elementos complejos o compuestos, la situación cambia. Incluso con los mismos parámetros de entrada, diferentes núcleos geométricos pueden producir resultados diferentes debido a las peculiaridades de su funcionamiento y algoritmos de procesamiento. Como resultado, las entidades geométricas del proyecto guardadas como geometría paramétrica se visualizarán de forma diferente en diferentes productos CAD (BIM).
Figura 9. Diferentes modelos paramétricos de entrada dan resultados diferentes cuando se utilizan diferentes núcleos geométricos
La compatibilidad total entre plataformas a nivel de geometría paramétrica sigue siendo inalcanzable para la mayoría de los proveedores de CAD. Esto se debe a la falta de estandarización de los algoritmos utilizados en los núcleos de geometría de los sistemas, que a menudo no son propiedad de los proveedores de CAD (y más aún de los proveedores de MCAD), así como a la necesidad de crear especificaciones de intercambio abiertas y desarrollar convertidores universales. Actualmente, solo un puñado de iniciativas, incluidas OpenCascade, Open Design Alliance y CADExchanger, están abordando estos desafíos. Históricamente, las iniciativas para convertir y unificar datos multiformato han surgidobajo intensa presiónde los proveedores de CAD. Sin embargo, muchos de estos conflictos han terminado enlitigiocon decisiones no favorables a los vendedores.
Entendamos por qué necesitamos un núcleo geométrico en el manejo de datos, que es tan complejo que incluso los desarrolladores de sistemas CAD (BIM) tienen que recurrir a proveedores y desarrolladores externos para obtener soluciones y desarrollos.
4. CAD, IFC y núcleos geométricos: ¿quién manda?
El núcleo geométrico es necesario para la visualización y el procesamiento de la geometría. Uno de los métodos más comunes de representación de la geometría en los sistemas CAD (BIM) es la representación de límites (BREP o B-rep).
BREP (Boundary Representation) es una forma de describir la geometría de un objeto a través de parámetros de contorno: superficies, aristas y vértices.
Otras formas de representación de geometría, como CSG y Swept Solids, se utilizan en formato IFC y contenedores internos de programas CAD, que encuentran su aplicación en determinadas tareas. Sin embargo, debido a su versatilidad, BREP es la forma líder de representación de geometría y se ha convertido en el estándar para la mayoría de las soluciones de ingeniería y arquitectura en el entorno CAD (BIM).
En cualquier programa CAD, las acciones del usuario, como los clics del mouse en la interfaz del programa para seleccionar puntos o líneas, se convierten a BREP mediante un núcleo geométrico (matemático) y se muestran como una forma terminada en la ventana del programa.
Sin embargo, dado que cada proveedor de CAD utiliza su propio núcleo de geometría con una base de código única, que a menudo consta de decenas de millones de líneas, la transferencia de parámetros BREP entre programas no garantiza su representación idéntica en otro sistema CAD.
Figura 10. Surgimiento de BREP paramétrico utilizando núcleo geométrico de forma de elemento
BREP (Boundary Representation) dentro del formato IFC no es un formato fundamental, ya que se describe de forma paramétrica sin utilizar un núcleo geométrico específico o existente para ello. Esto crea una situación en la que el mismo modelo IFC paramétrico puede interpretarse de forma diferente en diferentes productos de software que utilizan diferentes núcleos geométricos, como OpenCascade, Shape manager, Siemens Polarsolid, que se utilizan en programas CAD (BIM).
Un elemento clave en el proceso de creación de una verdadera interoperabilidad entre plataformas podría ser la idea utópica de crear un núcleo geométrico universal al que se puedan vincular los parámetros de los elementos. Esto garantizaría la correcta interpretación de la misma geometría en cualquier sistema CAD (BIM).
Por lo tanto, o bienConstrucción inteligentedebe tener su propio núcleo geométrico libre y abierto o el mismo elemento BREP del formato IFC seguirá mostrándose de forma diferente en diferentes herramientas y programas.
El propio IFC puede considerarse como una especie de CAD dentro de CAD o un esqueleto para un sistema de diseño asistido por ordenador, que en 30 años no ha aparecido oficialmente para el IFC.
5. IFC es CAD dentro de CAD con dependencia del núcleo de geometría y los SDK
El formato IFC utiliza diferentes formas de representar geometría, como CSG y Swept Solids, pero BREP también se ha convertido en el estándar líder para transferir geometría de entidades en formato IFC, ya que este formato es compatible al exportar desde programas CAD (BIM) y permite la posible edición (solo implementada en productos experimentales) de entidades al importar IFC nuevamente a programas CAD.
En la mayoría de los casos, cuando la geometría en IFC se define de forma paramétrica (BREP), resulta imposible obtener propiedades como el volumen o el área de las entidades del proyecto teniendo solo un archivo IFC, porque para trabajar con la geometría y su visualización en este caso se necesitará un núcleo de geometría, que inicialmente está ausente.
Para soportar IFC en cualquier programa es realmente necesario crear otro CAD IFC ideal dentro de la solución existente con su propio núcleo de geometría y su propia lógica de trabajo con geometría.
Figura 11. ¿Es posible estandarizar los núcleos de geometría y los SDK utilizados por los proveedores de CAD?
Y si bien puede que no haya problemas con los elementos primitivos en el formato IFC-BREP, además de los problemas con los diferentes motores de núcleo geométrico, hay suficientes elementos que tienen sus propias peculiaridades para un mapeo correcto. Este problema se analiza en detalle en el documento internacional “Estudio de referencia sobre el soporte de software IFC” publicado en 2019. Cita:
Los mismos conjuntos de datos estandarizados producen resultados inconsistentes, pocos patrones comunes detectables y se encuentran serios problemas en el soporte del estándar (IFC, nota del autor), probablemente debido a la altísima complejidad del modelo de datos estándar. Los propios estándares tienen parte de culpa en esto, ya que a menudo dejan algunos detalles sin definir, con altos grados de libertad y varias interpretaciones posibles. Permiten una alta complejidad en la organización y almacenamiento de objetos, lo que no favorece una comprensión universal efectiva, implementaciones únicas y un modelado de datos consistente.
La comprensión correcta de “ciertas disposiciones” está disponible para los miembros pagos deConstrucción inteligentey, a menudo, en discusiones tras bastidores. En consecuencia, quien quiera acceder a conocimientos importantes sobre determinadas características de la IFC intentará cooperar con grandes empresas o llegar a ellos mediante su propia investigación.De una entrevista con el desarrollador de laPrograma CADRenga:
Se encuentra con una pregunta sobre la importación y exportación de datos a través del formato IFC y pregunta a sus colegas proveedores: "¿Por qué la información sobre la transferencia paramétrica de instalaciones se transfiere en el archivo IFC de esta manera? La especificación abierta deConstrucción inteligente“No se dice nada al respecto”. Respuesta de los vendedores europeos “más informados”: “Sí, no se dice nada, pero está permitido”.
Fig. 10: El mismo proyecto IFC en diferentes programas CAD (BIM) da resultados diferentes
Todas las características de la generación y el mapeo de parámetros IFC en el núcleo geométrico sólo pueden ser implementadas por grandes equipos de desarrollo. Por lo tanto, la práctica actual de las características y la complejidad del formato IFC es beneficiosa principalmente para los proveedores de CAD y tiene mucho en común con la estrategia de "adoptar, extender, destruir" de Microsoft, donde la creciente complejidad del estándar en realidad crea barreras para los actores más pequeños del mercado. La estrategia de Microsoft fue adaptar estándares abiertos, agregar sus propias extensiones y características para crear dependencia del usuario en sus productos y luego expulsar a los competidores. Microsoft ha impuesto durante mucho tiempo sus propios estándares (por ejemplo, Internet Explorer), lo que ralentizó la adopción de tecnologías más avanzadas y universales como CSS, HTML5 o navegadores independientes.
Como resultado, hoy en día solo los grandes proveedores de CAD, que pueden invertir recursos significativos para respaldar todas las entidades y su mapeo a su núcleo de geometría interna, pueden implementar completamente la ontología IFC. Los grandes proveedores también tienen la capacidad de armonizar detalles técnicos de las características entre ellos que pueden no estar disponibles incluso para el participante más activo enConstrucción inteligente.
Obtenga más información sobre los desafíos que enfrentan los equipos de desarrollo que trabajan con formatos IFC en elEstudio de referencia sobre el soporte de software IFC
Fig. 12: Estudio internacional sobre la multiplataformabilidad del formato IFC
Para los pequeños equipos independientes y los proyectos de código abierto que quieren apoyar el desarrollo de formatos interoperables, la falta de un núcleo geométrico propio se convierte en un problema grave. Sin él, resulta prácticamente imposible tener en cuenta todas las sutilezas y matices asociados al intercambio de datos entre plataformas.
Actualmente, el único núcleo de código abierto ampliamente utilizado que sustenta las herramientas openBIM más populares (como IfcOpenShell, BlenderBIM-Bonsai, IFC.js y FreeCAD) es OpenCascade. Sin embargo, también tiene sus limitaciones.Construcción inteligenteLa organización no tiene herramientas directas para influir en el desarrollo y la concesión de licencias de OpenCascade (OCC). Históricamente, el equipo de desarrollo de OCC estaba centrado en Nizhny Novgorod, pero en los últimos años algunos especialistas de OCC se han trasladado a Portugal, y la parte más grande y restante del equipo se ha centrado en desarrollar una rama del proyecto OpenCascade (OCC) bajo la marca del nuevo proyecto chino de código abierto.núcleo de geometría OGG.
¿Y por qué necesitamos una geometría duramente conseguida en la construcción? ¿La necesitamos en forma paramétrica?
6. ¿Por qué los constructores necesitan geometría? Cuando las líneas se convierten en dinero
Además de la visualización, la geometría complementa las listas de parámetros de elementos existentes con características volumétricas clave, como el área y el volumen, que se calculan automáticamente en función de la forma del objeto de entidad del proyecto. Estos parámetros desempeñan un papel crucial, ya que sirven como base para los cálculos, los cálculos y los análisis posteriores.
El cálculo automático de la geometría se convierte en el vínculo entre los datos abstractos en forma de parámetros del problema y su realización física.
Históricamente, la geometría ha sido la base de la comunicación en ingeniería, ya que permite calcular longitudes, áreas y volúmenes. Desde los primeros dibujos en papiro hasta los formatos digitales modernos, los dibujos siempre han servido como una herramienta clave para comunicar información sobre cantidades de materiales y trabajo entre ingenieros, capataces y tasadores. Durante milenios, hasta la década de 1980, los tasadores recopilaban manualmente datos de cantidades y volúmenes basándose únicamente en representaciones visuales, utilizando reglas y transportadores como herramientas de medición principales.
Figura 13: Los principales propósitos de los datos geométricos en los procesos de negocio de la construcción
Con la llegada de las computadoras, la tarea manual y que consume mucho tiempo de calcular las características volumétricas ahora se resuelve mediante una automatización completa gracias a la llegada del modelado volumétrico en las modernas herramientas CAD (BIM), que permite obtener automáticamente los atributos volumétricos de cualquier elemento, sin necesidad de calcular estos valores manualmente con una calculadora.
En los programas CAD, la creación de elementos geométricos para los cálculos se realiza a través de la interfaz de usuario de los programas CAD-BIM. Para transformar puntos y líneas en cuerpos volumétricos se utiliza el núcleo geométrico. El núcleo geométrico realiza la tarea clave: la transformación de la geometría en modelos volumétricos, a partir de los cuales, tras la aproximación, se calculan automáticamente los volúmenes del elemento.
Fig. 14: Trayectoria de la visualización de formas geométricas fuera de los sistemas CAD (BIM)
Así como hace miles de años durante la construcción de las pirámides se utilizaban el codo y el codo para las mediciones, hoy en los programas CAD la precisión en la interpretación de la geometría juega un papel fundamental: de ello dependen la exactitud de los cálculos del presupuesto del proyecto, la determinación correcta del coste y el calendario de las obras que componen cualquier proyecto de construcción.
Los cálculos precisos son un factor clave para la supervivencia en la industria de la construcción. En un entorno altamente competitivo, el acceso a datos de volumen de calidad es crucial para la implementación exitosa de proyectos y el mantenimiento de la competitividad.
Si los cálculos precisos juegan un papel clave a la hora de determinar los recursos, materiales y parámetros de tiempo de un proyecto, es importante entender exactamente cómo se realizan estos cálculos.
7. Fundamentos de cálculos en construcción o de líneas a volúmenes: Cómo el área y el volumen se convierten en números
En la práctica, la triangulación se utiliza a menudo para calcular áreas y volúmenes de superficies geométricas definidas analíticamente o mediante NURBS en BREP, que convierte superficies complejas en una cuadrícula de triángulos.
NURBS (B-Splines racionales no uniformes) es una forma matemática de describir curvas y superficies, mientras que BREP es una estructura para describir la geometría tridimensional completa de un objeto, incluidos sus límites, que pueden definirse utilizando NURBS.
Incluso si la superficie se proporciona analíticamente o mediante NURBS, la mayoría de las veces se aproxima mediante teselación, ya que en la práctica rara vez se realizan cálculos exactos mediante integrales o métodos analíticos complejos debido a su complejidad y alto costo computacional.
La esencia de la teselación es descomponer superficies complejas en elementos más simples: triángulos o polígonos. Este enfoque se utiliza para cálculos de superficies y volúmenes, visualización en pantalla, exportación a formatos como MESH (“malla”) y sistemas de análisis de colisiones. En los juegos, la teselación se utiliza para crear paisajes realistas y en los sistemas CAD/CAE para computación y visualización. Los panales de abejas son un ejemplo de teselación en la naturaleza.
Figura 15: BREP y representación poligonal de la esfera
BREP (NURBS) utilizado en CAD (incluidos los sistemas BIM) no es un modelo fundamental de geometría. Este método fue creado como una herramienta conveniente para representar círculos y splines racionales. Sin embargo, tiene limitaciones, por ejemplo, la incapacidad de describir con precisión la sinusoide que subyace a las líneas y superficies helicoidales. Como resultado, BREP (NURBS) sigue siendo solo un método de aproximación, pero no un medio fundamental para describir la geometría.
Por el contrario, las mallas de triángulos y la teselación paramétrica se caracterizan por su simplicidad, uso eficiente de la memoria y capacidad para procesar grandes cantidades de datos. Estas ventajas permiten prescindir de núcleos geométricos complejos y costosos y de cientos de millones de líneas de código a la hora de calcular formas geométricas.
Figura 16. Ejemplos de teselación de cilindros y cubos
En la industria de la construcción, no importa cómo se determinen las características volumétricas: mediante modelos paramétricos en formatos CAD o IFC internos, o mediante representaciones geométricas simplificadas en formatos USD, glTF, DAE u OBJ.
La geometría definida como polígonos o BREP (NURBS) son formas de aproximarse a una forma continua. Así como las integrales de Fresnel no tienen una expresión analítica exacta, la discretización de la geometría a través de polígonos o NURBS es siempre una aproximación, al igual que la malla triangular.
Tanto el modelo MESH poligonal como el BREP paramétrico tienen sus ventajas y limitaciones, pero el objetivo es el mismo: describir la geometría de manera eficiente y conveniente, teniendo en cuenta las tareas del usuario. Al final, la precisión del modelo geométrico depende no solo del método de su representación, sino también de los requisitos de una tarea en particular.
Fig. 17: Diferencia de características volumétricas de figuras con diferente número de polígonos
La geometría paramétrica en formato BREP es necesaria sobre todo cuando el tamaño de los datos es mínimo y es posible utilizar núcleos geométricos costosos y que consumen muchos recursos para su procesamiento y visualización. En la mayoría de los casos, esto es característico de los programas CAD que utilizan núcleos geométricos de proveedores MCAD para este fin.
En la mayoría de las aplicaciones de construcción, la necesidad de geometría paramétrica y núcleos de geometría complejos es poco común, a menos que su importancia sea promovida por los propios proveedores de CAD o por los proveedores de núcleos de geometría que desarrollan estas herramientas.
Como resultado, dentro de los programas CAD (BIM), la geometría paramétrica (BREP, RVT, IFC, PLN) todavía se convierte en triángulos y polígonos MESH para los cálculos a través del proceso de teselación. Fuera del entorno CAD (BIM), en la mayoría de los casos, la geometría MESH triangulada (USD, SVF, glTF, CPIXML, DAE, NWC) también se utiliza para la visualización, el cálculo y la búsqueda de colisiones, lo que hace que la necesidad de la geometría paramétrica sea aún menos obvia.
Entonces, ¿qué formato debería elegirse como estándar para el intercambio de datos? ¿IFC es el formato apropiado para el intercambio: IFC-MESH triangular (gLTF, OBJ, DAE, SVF) o IFC-BREP paramétrico (RVT, PLN, DGN)?
8. ¿Por qué necesitamos triángulos? Uso de teselación en la construcción
Un programa CAD (BIM) específico no debe ser la base del formato de intercambio que se utilizará tanto en los departamentos de cálculo de costes como en la obra. La información geométrica debe presentarse en el formato directamente, sin referencia a un núcleo geométrico o arquitectura CAD.
En la industria de la construcción, en los sistemas y bases de datos que utilizan datos de diseño, se debe minimizar la dependencia del editor CAD y del núcleo de geometría.
Los parámetros geométricos de los programas CAD pueden formar parte del proceso, pero solo como datos de entrada, no como base para un formato de intercambio. Esta es la única forma de garantizar la universalidad e independencia de las descripciones geométricas. La mayoría de las geometrías paramétricas, incluidas las BREP y las NURBS, se convierten en una malla triangular (teselación) para su cálculo y visualización. Después de la teselación, se obtiene una MALLA triangular. Si no se puede ver la diferencia al final, ¿por qué complicar el proceso?
Los formatos paramétricos no son fundamentales y, por el contrario, formatos como OBJ, STL, gLTF, SVF, CPIXML, USD y DAE siguen siendo fundamentales porque utilizan la estructura simple y universal Triangle MESH. Es comprensible y eficiente en la arquitectura de gráficos por computadora y no requiere núcleos de geometría adicionales con decenas de millones de líneas de código para la visualización o los cálculos de elementos.
Fig. 18: Transición de la geometría del formato paramétrico a la representación poligonal
Debido a problemas con la interpretación de IFC y las diferencias geométricas del núcleo, todos los proveedores de CAD, sin excepción, utilizan SDK de ingeniería inversa para transferir datos entre soluciones de diferentes proveedores ynadie usaformato IFC o USD complejo para fines de interoperabilidad.
El formato MESH USD, ofrecido a partir de 2023 por los proveedores de CAD en la nueva alianza AOUSD analizada en el artículo de la semana pasada (Una era de cambio: IFC es cosa del pasado o por qué ADSK y otros proveedores de CAD están dispuestos a renunciar a IFC por USD en 14 hechos clave), tiene el potencial de convertirse en el nuevo estándar para reemplazar la geometría paramétrica en formatos propietarios. También puede servir como un medio para describir la geometría BREP en IFC, algo que los propios proveedores de CAD no han logrado hacer hasta ahora.
Pero en lugar de utilizar conceptos promovidos por alianzas de proveedores de CAD que ellos mismos no utilizan, es más productivo centrarse en comprender los beneficios de cada enfoque en un contexto específico y elegir uno u otro tipo de geometría según el caso de uso.
La elección entre diferentes representaciones geométricas es un equilibrio entre la precisión, la eficiencia computacional y las necesidades prácticas de un problema particular.
Figura 19: Esfera BREP teselada con diferente número de polígonos
La complejidad y el uso de núcleos geométricos que los proveedores de CAD imponen a la industria de la construcción en el procesamiento de datos de diseño pueden no ser necesarios en absoluto. El formato USD con geometría MESH puede ser una caja de Pandora para la industria, abriendo enfoques alternativos al intercambio de datos IFC y BREP para los diseñadores. Resultó que existen otros formatos más simples y abiertos que pueden proporcionar una interacción de calidad entre los ingenieros de CAD (BIM) y docenas de otros especialistas.
Uno de los sistemas ERP de construcción más populares, ITWO/MTWO, es un ejemplo de una aplicación eficaz de la geometría MESH en los procesos de negocio de las empresas de construcción. Este producto, propiedad de la asociación franco-alemana de Schneider Electric y RIB Software, demostró el uso del formato MESH con un esquema simplificado de almacenamiento de metainformación a mediados de la década de 2000. En lugar de los formatos IFC y USD, ITWO/MTWO utiliza el formato propietario pero legible CPIXML.
Detrás del desarrollo del sistema ERP iTWO/MTWO se encuentra la empresa constructora Strabag, y más concretamente su filial Züblin de Stuttgart. Fue Züblin la que inició el desarrollo de iTWO, que en aquel momento no se posicionaba solo como un sistema ERP, sino como una plataforma internacional para BIM 4D-5D, es decir, la integración de datos de diseño con cronogramas y estimaciones.
9. El intento de Zublin-Strabag de subordinar a los proveedores de CAD (BIM) a los intereses de la industria de la construcción
Züblin-Strabag es una de las empresas de construcción más grandes de Europa y posee un profundo conocimiento de todas las fases del proceso de construcción. Facturación de STRABAG SEalcanzó 17,67mil millones de euros en 2023. En comparación, el tamaño total del mercado global de empresas de software CAD, incluida ADSK, se estimóenalrededor18.540 millones de dólares en 2021.
Los desarrolladores de Zublin (Strabag) y RIB Software en Stuttgart han sido capaces de crear convertidores plug-in para programas CAD básicos que toman datos geométricos y los teselan en el formato OBJ CPIXML (similar a USD). Como resultado, estas geometrías trianguladas han hecho posible calcular más de 150 características volumétricas diferentes basadas en la geometría primitiva MESH OBJ más allá de los programas CAD (BIM) en un ERP tabular, además de las ya obtenidas dentro del propio programa CAD. Tras la venta de ITWO a la francesa Schneider Electric por 1.500 millones de euros, Züblin (Strabag) se ha centrado en la creación de un nuevo producto para la interoperabilidad en la industria de la construcción.
Figura 20: Historia de las golondrinas de Zublin-Strabag y el surgimiento del núcleo geométrico OGG
Desde mediados de la década de 2010, Züblin (Strabag) ha estado desarrollando una plataforma llamada SCOPE, que adquiere geometría de varios programas CAD a través de conexiones API y el SDK de ingeniería inversa y la convierte en un formato neutro basado en OpenCascade. Esto permite que los datos de geometría se utilicen en varios casos comerciales sin estar vinculados a programas CAD (BIM) específicos. La idea principal del proyecto es separar la gestión de datos del proyecto de las aplicaciones CAD y garantizar la independencia de los usuarios con respecto a las herramientas específicas del proveedor. La descripción del proyecto SCOPE se hace eco de la idea de Samuel Geisberg (creador de PTC y mentor del proyecto Revit), que buscaba reducir la influencia de los programas CAD en los procesos de cambio y adición de datos:
Durante los primeros ocho meses del proyecto, el consorcio logró generar las primeras descripciones completas de componentes en los formatos RDF y OWL de la World Wide Web. Para ello, la funcionalidad del núcleo geométrico openCASCADE se convirtió en estructuras direccionables por la web. El objetivo declarado de SCOPE es crear estructuras web para superar las barreras de la digitalización. Para ello, todos los componentes de un gemelo digital de un edificio se muestran independientemente del software y se hacen accesibles a través de interfaces web. Si se logra el éxito, esto significa que todas las actividades de digitalización necesarias para crear un gemelo de edificio por parte de todas las empresas, disciplinas especializadas e industrias involucradas se pueden realizar de forma independiente entre sí y, a la vez, estar interconectadas. Siempre que el contenido se proporcione sobre la misma base técnica, es decir, una única estructura de servidor y un único esquema de datos.
Figura 21: Proyecto semántico SCOPE del equipo Züblin-Strabag
La idea del proyecto SCOPE es, sin duda, prometedora y necesaria para el sector, pero el proyecto se lleva a cabo en el ecosistema cerrado de Zublin-Strabag, en el que los equipos de desarrolladores y gerentes cambian constantemente, lo que puede dar lugar a un sistema engorroso e ineficiente con plazos de realización de proyectos más largos. El proyecto Züblin basado en OpenCascade también se enfrenta a las limitaciones técnicas del propio núcleo geométrico de OpenCascade y a la API en constante cambio de los programas CAD. Queda por ver si una empresa compuesta por especialistas de indudable talento puede hacer frente a estos problemas.
En resumen, dadas las limitaciones a las que se enfrentan los desarrolladores, SCOPE no puede considerarse una solución completa por el momento. Un desarrollo creado por una organización privada para uso interno no es una herramienta universal.
Por otra parte, los propios proveedores de CAD están dando un paso hacia la simplificación yQuiero darle a la industria de la construcción unanuevo formato de cambio del USD, similar al formato CPIXML que ya cubre todos los procesos 4D-7D en las empresas de construcción de Europa Central.
Como resultado, las empresas de la industria de la construcción se enfrentan a una elección en el futuro: seguir los enfoques propuestos por Züblin y el Instituto Fraunhofer, o adoptar soluciones promovidas por HOK y los proveedores de CAD a través deConstrucción inteligenteo alianza AOUSD.
Sin embargo, ambos enfoques, ya sea que provengan de la industria de la construcción o del mundo CAD, llegan a la misma conclusión: para un intercambio de datos eficiente, tiene sentido utilizar formatos simples de almacenamiento de metainformación plana y formatos triangulados como OBJ, CPIXML, DAE, SVF, gLTF o USD que almacenan los mismos datos de elementos.
Fig. 22: Diferentes formatos de datos contienen geometría idéntica y metainformación de los elementos del proyecto
Después de revisar la transferencia de geometría y las complejidades relacionadas, pasemos a analizar la segunda parte integral de los formatos CAD (BIM): la metainformación y la ontología semántica de los elementos, que se menciona en los comunicados de prensa oficiales de SCOPE yConstrucción inteligenteequipo.
Similar a laConstrucción inteligenteEn este enfoque, Züblin ha aplicado el concepto de semántica de datos a su plataforma SCOPE. La base de este enfoque es la idea de la web semántica propuesta por Tim Berners-Lee. Su objetivo es crear una semántica inteligente en la que los datos estén estructurados de tal manera que puedan ser comprendidos no solo por humanos sino también por máquinas.
10. Surgimiento de la semántica y la ontología en la construcción
La estandarización y unificación en la construcción tomó prestada la introducción de la semántica y la ontología del concepto de la web semántica a finales de los años 1990. Este concepto fue adaptado en el contexto deConstrucción inteligentepara el estándar IFC. La idea básica detrás de la semántica es que los datos deben tener sentido no solo para los humanos sino también para las máquinas, permitiéndoles "entender" la información en lugar de simplemente transmitirla. La ontología, a su vez, crea definiciones claras de términos y sus relaciones, lo que proporciona un marco unificado para todos los sistemas.
Construcción inteligenteha intentado aplicar este enfoque a toda la industria de la construcción. En uno de los puntos clavedocumentos sobre el futuro deEl IFC5formato,titulado “El futuro de las clases fundamentales de la industria: hacia IFC 5”, el enfoque semánticose menciona 32 veces, destacando su importancia para el desarrollo futuro de la norma:
En particular, en el ámbito de la Web Semántica, se ha invertido mucho esfuerzo en transformar, modularizar y simplificar el esquema IFC (u ontología, según el término típico en este ámbito). Se comenzó con una transformación sencilla del esquema IFC EXPRESS y modificaciones que llevaron a una ontología más idiomática (Beetz et al. 2009), así como análisis destinados a introducir la modularidad (Terkaj y Pauwels 2017).
El objetivo deConstrucción inteligenteEl objetivo es crear un único estándar universal para describir objetos y sus relaciones. Este enfoque debería ser aplicable en todo el mundo de la construcción, garantizando la unificación de datos y mejorando su interpretación por parte de diferentes sistemas. Comprar membresía enConstrucción inteligenteofrece a las empresas miembros no sólo la oportunidad de unirse al futuro, sino también de influir activamente en su formación hoy.
Figura 23: Cita de 1994 del presidente de la junta directiva internacional de BuildingSmart
Sin embargo, la implementación de la semántica y las ontologías no siempre tiene éxito. La realidad ha demostrado ser mucho más compleja. En la industria de los juegos, los intentos de describir los objetos y las interacciones del juego mediante ontologías han encontrado problemas debido a la alta dinámica de cambio y la naturaleza creativa de la industria. Como resultado, los formatos de datos estándar (XML, JSON) y los algoritmos demostraron ser más eficientes. Una situación similar se observó en el mercado inmobiliario, donde la variedad de términos locales y los cambios rápidos hicieron que las ontologías fueran demasiado complejas. Bases de datos y estándares simplescomo RETStuvo un mejor desempeño en el intercambio y procesamiento de datos.
No se deben crear nuevas entidades a menos que sea absolutamente necesario
La navaja de Occam
Las dificultades técnicas, como la complejidad del marcado y la elevada intensidad laboral del soporte, así como la baja motivación de los desarrolladores, obstaculizaron el desarrollo de esta idea en otras industrias. RDF (Resource Description Framework) no se convirtió en un estándar masivo y las ontologías demostraron ser demasiado complejas y económicamente injustificables. Como resultado, la ambición de crear una web semántica global no se materializó. Algunas ideas se han adaptado en soluciones corporativas, pero el objetivo original de crear un único gráfico integral no se ha logrado.
Figura 24. Comparación de bases de datos relacionales y ontológicas
Las ontologías y las tecnologías semánticas prometían crear significado a partir de los datos, pero en la práctica funcionan más como un mecanismo de unificación y estandarización. Pasar de tablas a gráficos de datos mejora la búsqueda y unifica el modelo de datos, pero no hace que los datos sean más significativos para las máquinas. La cuestión no es si se deben utilizar tecnologías semánticas, sino dónde realmente marcan la diferencia.
El interés por las tecnologías semánticas y las ontologías en la industria de la construcción está respaldado por laConstrucción inteligenteSin embargo, la necesidad de una lógica formal completa y la creación de una ontología unificada para toda la industria sigue siendo un punto controvertido. La experiencia de los proyectos CYC (“enciclopedia”) y de la web semántica muestra que abandonar la idea de una única ontología universal en favor de microteorías locales aplicables sólo dentro de una tarea, proyecto o empresa específica puede ser un enfoque más productivo.
11. Semántica y ontología: ¿cómo hacer que los datos hablen?
Gracias al esfuerzo deConstrucción inteligenteLa semántica y las ontologías se han convertido no sólo en la idea clave detrás de la estandarización impulsada por los proveedores de CAD, sino también en la base de proyectos como SCOPE, promovido por Züblin (Strabag), y cuyo objetivo es liberar a la industria de la construcción de la dependencia de los sistemas CAD.
Las tecnologías semánticas son la unificación, estandarización y modificación de grandes conjuntos de datos heterogéneos, así como la implementación de búsquedas complejas. Sin embargo, la semántica no está relacionada de ninguna manera con la creación de nuevos significados o conocimientos; en este sentido, no es superior a otras tecnologías de almacenamiento y procesamiento de datos.
Representar los datos de una base de datos relacional como un conjunto de tripletes no añade significado a los datos en sí. Reemplazar las tablas por un gráfico puede ser útil para unificar el modelo de datos, implementar búsquedas complejas y modificar de forma segura los modelos de negocio. Sin embargo, no hace que los datos sean más “inteligentes”: la computadora no empieza a entender mejor su significado.
Cuando se trata de almacenar “datos OWL”, estos datos se almacenan utilizando tripletes RDF (RDF, Resource Description Framework y OWL, Web Ontology Language).
Figura 25: Modelo de datos gráficos: nodos, aristas y triples que ilustran las relaciones entre los bloques de construcción
En teoría, la inferencia lógica de los risoners (programas para la inferencia lógica automática) permite derivar nuevos enunciados basados en ontologías. Por ejemplo, si una ontología de construcción registra que “una base es un soporte para una pared” y “una pared es un soporte para un techo”, el risoner puede inferir automáticamente que “una base es un soporte para un techo”. Este mecanismo es realmente útil para optimizar el análisis de datos, ya que elimina la necesidad de explicar explícitamente cada dependencia. Sin embargo, no crea nuevos conocimientos, sino que simplemente compara automáticamente hechos ya conocidos.
Los vínculos lógicos en la ontología, si son necesarios, se pueden organizar sin tecnologías semánticas complejas, por ejemplo, utilizando bases de datos relacionales (SQL) o tablas CSV y XLSX. En bases de datos y formatos en columnas, es posible agregar una columna “soporte del techo” y garantizar mediante programación que el hecho de que el techo esté vinculado a la base se agregue cuando se crea el muro. Esto se logra sin el uso de RDF, OWL, gráficos o resolvers.
Fig. 26: Comparación de modelos gráficos y tabulares de representación de las mismas relaciones lógicas
La decisión deConstrucción inteligenteEl concepto de web semántica, que parecía prometedor y popular a finales de los años 90, ha influido en toda la industria de la construcción. Sin embargo, la paradoja es que el concepto de web semántica, que se propuso originalmente para Internet, no se ha utilizado ampliamente ni siquiera en su entorno nativo. En Internet, para el que se desarrollaron RDF y OWL, estos conceptos apenas se utilizan hoy en día. Nunca ha aparecido una web semántica completa en la arquitectura original y probablemente no se prevea su creación.
La idea de crear una Internet en la que los ordenadores pudieran comprender el significado del contenido resultó demasiado compleja y poco económica. Por eso, las empresas que en un principio apoyaron la web semántica abandonaron únicamente los elementos útiles de la tecnología (como las ontologías y SPARQL) y los aplicaron a fines corporativos en lugar de a Internet en su conjunto. Si se observan las tendencias de Google, por ejemplo, de los últimos 20 años, se puede ver que es posible que ya no haya perspectivas de futuro.
Fig. 27: Interés en el tema de la web semántica según las estadísticas de consultas de Google
Surge aquí una pregunta lógica: ¿por qué utilizar tripletes, rizoners y SPARQL en la construcción, si se pueden procesar datos mediante consultas estructuradas populares (SQL, Pandas, Apache)? En las aplicaciones empresariales, SQL es el estándar para trabajar con bases de datos. SPARQL, por el contrario, requiere estructuras gráficas complejas y software especializado y, según las tendencias de Google, no atrae el interés de los desarrolladores.
Las bases de datos gráficas y los árboles de clasificación pueden ser útiles en algunos casos, pero su aplicación no siempre está justificada para la mayoría de las tareas cotidianas. Por ello, la creación de gráficos de conocimiento y el uso de tecnologías de la web semántica solo tiene sentido cuando es necesario unificar datos de diferentes fuentes o sacar conclusiones lógicas complejas. Para las tareas cotidianas, como la gestión de datos de construcción, las bases de datos relacionales, CSV, SQL y Excel siguen siendo herramientas más sencillas, accesibles y eficientes.
12. De gráficos a tablas: costos laborales en agrupación y filtrado
Cualquier ontología y relación describe fundamentalmente los parámetros de los elementos y entidades del proyecto mediante pares clave-valor. La única pregunta es cómo comunicar estos parámetros del diccionario clave-valor y en qué forma. La diferencia no está en el mecanismo o la estructura de almacenamiento, sino en la profundidad de la comprensión semántica y la capacidad de hacer conexiones significativas entre conceptos. Si el marcado exprés y la ontología IFC son la herramienta ideal para esto es una gran pregunta.
Fig. 28: La información sobre las entidades de los elementos se almacena en formato clave-valor como diferentes formas de representación.
En otras industrias, los elementos con parámetros, geometrías y problemas de transferencia de ontología son similares. Sin embargo, los especialistas de estas industrias transfieren metainformación utilizando formatos populares como XML, DB, JSON, CSV, HD5 y XLSX. Surge una pregunta lógica: ¿por qué en la industria de la construcción decidimos transferir metainformación utilizando tecnologías desarrolladas en los años 70 para el formato IGES-STEP en marcado EXPRESS línea por línea, que se inventó en la época de las tarjetas perforadas? Sí, existen convertidores para convertir datos de IFC a JSON, XML, CSV o XLSX. Sin embargo, surge la pregunta: ¿por qué utilizar un paso intermedio con IFC?
Es mucho más lógico descargar datos de programas CAD directamente en formatos JSON, XML o CSV/XLSX estructurados utilizando SDK de ingeniería inversa, que son utilizados porTodos los proveedores de CAD sin excepciónEn este caso, el uso del IFC como paso intermedio pierde su sentido. Y si no hay diferencia en la completitud de la información entre gráficos y tablas, la elección se reducirá únicamente a la elección del esquema de datos y del formato de registro.
La forma y el esquema de los datos deben adaptarse al caso de uso para tareas específicas.
Figura 29: La estructura del gráfico y la tabla contienen información idéntica sobre los elementos del proyecto
El formato gráfico semántico solo simplifica la creación de nuevas relaciones, es decir, permite agregar nuevos tipos de datos al gráfico sin realizar cambios en la estructura de almacenamiento.
En comparación con las tablas relacionales, en un gráfico no existe una conectividad de datos adicional especial: traducir datos de una base de datos bidimensional a un gráfico no aumenta la cantidad de relaciones ni permite obtener nueva información.
Para incorporar datos a los procesos de negocio, debemos esforzarnos en utilizar aquellas herramientas que nos ayuden a obtener resultados lo más rápido y fácilmente posible.
La tarea principal al procesar datos de modelos CAD (BIM) y bases de datos sigue siendo la misma: la agrupación y el filtrado rápidos de la base de datos de proyectos común de un grupo determinado para extraer información clave. Los resultados de este trabajo se presentan en forma de tablas, gráficos o documentos, lo que permite tomar decisiones comerciales fundamentadas basadas en datos.
Figura 29: Uno de los principales casos de uso de los datos de diseño en la construcción es la agrupación y el filtrado de QTO
A pesar de que los datos de entrada y salida son idénticos, los enfoques y el tiempo necesarios para realizar estas operaciones pueden variar significativamente según los sistemas CAD (BIM) utilizados y, más específicamente, los formatos, esquemas de datos y enfoques conceptuales utilizados en ellos.
Por ejemplo, la tarea de obtener una tabla de volúmenes para todos los tipos de elementos de la misma categoría (tomemos el ejemplo de la categoría de muros: OST_Walls, IfcWalls) del proyecto se ve diferente según la herramienta. En la GUI de Revit, se necesitan 17 clics del mouse para agrupar y recuperar la tabla. El uso de Dynamo para Revit le permite automatizar el proceso, pero requiere importar y vincular 13 bloques de código en un IDE especial de IronPython. Escribir un script de Python para Revit requeriría 40 líneas de código y conocimiento de APU, lo que proporciona más flexibilidad pero requiere más esfuerzo por parte del ingeniero o programador.
Trabajar con archivos IFC a través de la interfaz del programa Solibri es similar a Revit en términos de intensidad de trabajo: aquí, para obtener una tabla simple con volúmenes del proyecto, también necesitará realizar 17 clics con el mouse. Al usar la biblioteca de Python IfcOpenShell o JavaScript IFC.js, el procesamiento se automatiza, pero esto nuevamente requiere escribir alrededor de 40 y más de 100 líneas de código, respectivamente.
Además, el problema de los formatos propietarios y de las herramientas CAD (BIM) es que, por un lado, proporcionan un entorno cómodo para desarrollar algoritmos propios para automatizar los procesos de producción. Sin embargo, por otro lado, estos algoritmos quedan rígidamente ligados a un formato de datos específico o a la forma en que se interpretan. Como resultado, la automatización pierde su universalidad y comienza a depender de las particularidades del formato, en lugar de trabajar con entidades y ser independiente de las limitaciones técnicas.
Figura 30: Se logra el mismo resultado con diferentes insumos laborales
Al normalizar y estructurar datos de formatos de proyectos CAD sin necesidad de abrir programas CAD (BIM), sino utilizando, por ejemplo, herramientas de ingeniería inversa, obtenemos acceso al uso de herramientas de análisis de datos para agrupar, filtrar y analizar. Con las herramientas de análisis de datos, las operaciones de agrupación, filtrado y procesamiento se realizan literalmente con una línea de código, mientras que en los sistemas CAD tradicionales y los conceptos BIM, donde los datos se representan como gráficos, hay que pasar por jerarquías y clases para llegar a los elementos. Como resultado, las mismas acciones que requieren docenas de clics en la interfaz de usuario, cientos de líneas de script, se pueden realizar de forma más rápida y sencilla al procesar datos en formatos estructurados.
Son datos estructurados y normalizados que brindan a los ingenieros la capacidad de moverse rápida y eficientemente entre diferentes tipos de datos, eliminando la necesidad de aprender esquemas de formato únicos, características de interfaz, conexiones API y núcleos de geometría.
Figura 31. En un formato de datos gráfico, los usuarios obtienen los datos que necesitan mediante una API o una interfaz de usuario.
La normalización y estructuración de los datos proporciona flexibilidad en el procesamiento sin necesidad de realizar un esfuerzo significativo para comprender el esquema de datos para cada caso de uso individual. ADSK está adoptando la misma idea en 2023, anunciando una nueva era dedatos granulares, donde ya no habrá un sistema de archivos, y los proyectos se dividirán en elementos mínimos, como es el caso del análisis de datos y los formatos estructurados.
Si los proveedores de CAD están desarrollando nuevos formatos y formas de trabajar con datos para sus clientes, ¿quién es responsable de los formatos y procesos de datos para toda la industria de la construcción y quién está involucrado en la creación de estándares para su uso?
13. A la sombra de ISO y BuildingSmart: la guerra por el control del formato de los datos
Los problemas de los datos CAD-MCAD multiplataforma los encontraron por primera vez los especialistas en ingeniería mecánica, que a menudo tienen que trabajar con formatos STEP e IGES (el predecesor ideológico de IFC) para transferir información entre productos MCAD, mientras que, como en la industria de la construcción, los especialistas luchan con núcleos geométricos multiplataforma. Citado del artículo “Cómo elegir el mejor formato de archivo CAD":
Todos los sistemas CAD también tienen un núcleo de modelado geométrico que subyace al formato nativo y permite crear y manipular geometría. CATIA utiliza Convergence Geometric Modeler (CGM), Creo utiliza Granite (g) y Siemens NX y SOLIDWORKS utilizan el núcleo Parasolid (x_t).
El núcleo de modelado geométrico es exactamente el mismo que el formato nativo en términos de geometría pura, ya que el formato nativo de cualquier sistema CAD se basa en su núcleo de modelado geométrico. No se puede obtener una mayor precisión geométrica que con el formato del núcleo siempre que se utilice el núcleo para la aplicación de origen o final. Por ejemplo, si tiene una pieza de CATIA y desea abrirla en MasterCam, guárdela en formato de núcleo Parasolid, porque es en eso en lo que se basa la aplicación de software MasterCam.
Figura 32. Calidad de los datos en formatos Cerrado (Closed BIM) y Abierto (Open BIM)
Programas como Revit (basado en Pro/Engineer) y AutoCAD (basado en CADDS 3), así como la mayoría de los núcleos geométricos modernos, incluido el de código abierto OpenCascade, llegaron a la construcción desde la ingeniería mecánica. Fue en este sector donde se crearon estándares de intercambio de datos como STEP (análogo al IFC para la ingeniería mecánica).
En general, aunque los problemas de los ingenieros mecánicos al trabajar con formatos son similares y nos llevan a los problemas del uso de núcleos geométricos, los enfoques para estandarizar y promover estos formatos en las industrias de la ingeniería mecánica y la construcción son marcadamente diferentes.
A diferencia de la construcción, donde el estándar IFC es desarrollado y promovido porConstrucción inteligenteLas normas en ingeniería mecánica se forman a nivel de la Organización Internacional de Normalización (ISO). En la ISO, las normasse desarrollan con participación igualitaria deTodos los países miembros participan en la elaboración de la norma, lo que hace que el proceso sea global y más independiente. La ISO puede considerarse como la «Naciones Unidas para la normalización», con su sede central en Ginebra.
El estándar STEP essiendo desarrollado por TC 184, un comitéafiliado al Instituto Nacional de Estándares de Estados Unidos (ANSI). Su historia se remonta al proyecto IGES, lanzado en 1979 por un grupo de usuarios y proveedores de CAD, entre los que se encontraban Boeing, General Electric, Xerox, Computervision y Applicon. El proyecto recibió el apoyo del Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) y del Departamento de Defensa de Estados Unidos, y su desarrollo fue financiado por el complejo militar-industrial y controlado por el ejército. Más tarde, se creó el estándar STEP sobre la base de IGES, y su rama en los años 90 se convirtió en IFC. A diferencia de las iniciativas abiertas, todas las decisiones clave sobre el desarrollo del estándar STEP se tomaron entre bastidores, sin publicidad ni ruido excesivos.
STEP es un estándar francamente norteamericano: su uso no es impuesto a los ingenieros mecánicos; si quieres usarlo, úsalo, si no quieres usarlo, no hay problema.Construcción inteligente, creada originalmente en 1994 para promover los intereses de HOK y ADSK, con la construcción de STEP-IFC se posiciona como una iniciativa global que aboga por la interoperabilidad y soluciones universales para todo el mundo.
A diferencia deConstrucción inteligenteLos desarrolladores de STEP no se dedican a vender suscripciones ni a crear divisiones como capítulos y salas a través de las cuales recolectar contribuciones para promover un formato paramétrico sin su propio núcleo geométrico y ontología semántica que se supone que debe hacer lo que la web semántica no ha podido hacer.
Pero ni siquiera el intento de llevar STEP-IFC a la industria de la construcción y la creación de alianzas permiten superar el caos creado por los formatos de intercambio. La situación ha llegado a un punto en el que incluso los propios proveedores de CAD ya no pueden soportar IFC en sus productos sin el uso de SDK especiales, que analizamos en detalle en el artículoLucha por los datos abiertos en el sector de la construcción. Historia de AUTOLISP, intelliCAD, openDWG, ODA y openCASCADE
Figura 33. Artículo: La era del cambio: la IFC es cosa del pasado o por qué ADSK está dispuesta a renunciar a la IFC por el dólar estadounidense
14. ¿Por qué los constructores y los clientes necesitan controlar los datos?
La creación de datos en la construcción es un proceso continuo de generación de parámetros y su conversión a formatos legibles. Cada entidad del proyecto (una pared, una ventana o una base) es un objeto con un conjunto de atributos, como material, tipo, coste, volumen y superficie. Estos datos deben almacenarse en algún lugar, procesarse y ponerse a disposición de los usuarios finales.
Los desarrolladores de programas CAD (BIM) se esfuerzan por mantener a los usuarios en su ecosistema y cada año trasladan cada vez más el procesamiento de datos a socios de almacenamiento en la nube como Amazon, Microsoft Azure y Huawei. La principal ventaja de marketing de los sistemas cerrados es la disponibilidad de transferencia de geometría de alta calidad desde el núcleo geométrico de las soluciones CAD (BIM) al formato MESH en la nube y la capacidad de importar/exportar formatos de terceros de otros proveedores utilizando costosos SDK para ingeniería inversa.
Pero, ¿por qué los ingenieros, los especialistas en logística, los constructores, los capataces y los tasadores necesitan núcleos geométricos y tecnologías en la nube? La precisión de los formatos teselados es suficiente para la mayoría de las tareas de construcción, y el uso de núcleos geométricos complejos y SDK solo complica el proceso.
Figura 34. La industria de la construcción se enfrenta a una transición inevitable hacia datos estructurados abiertos y herramientas abiertas
La mayoría de los motores gráficos modernos funcionan específicamente con mallas de triángulos, no con geometría BREP. La ironía es que todos los proveedores de CAD siguen promoviendo de forma persistente núcleos de geometría complejos, a veces no propios, mientras que la visualización, la simulación y la animación se están trasladando gradualmente a herramientas populares y gratuitas para uso no comercial: Blender, Unity, Unreal Engine y Omniverse.
Al abandonar la geometría paramétrica para el intercambio y procesamiento de datos en favor de la geometría MESH, se reducirá significativamente la dependencia de los programas CAD y los núcleos geométricos. Esto hará que el manejo de datos sea más transparente y acelerará el desarrollo de formatos ya populares como OBJ, gLTF, DAE y USD. Reconociendo esta tendencia, los proveedores de CAD se esfuerzan por mantener a los usuarios dentro de sus ecosistemas. Para ello, promueven formatos de interoperabilidad "fáciles de usar" que se posicionan formalmente como abiertos. Sin embargo, en la práctica, exportarlos requiere una suscripción a programas CAD (BIM), y el procesamiento requiere conocimientos de API y habilidades en el mapeo de características de núcleos geométricos complejos.
En el mundo actual del diseño y la construcción, la complejidad del acceso a los datos ha llevado a una ingeniería excesiva en la gestión de proyectos. Las empresas de construcción y diseño medianas y grandes se ven obligadas a mantener relaciones estrechas con los proveedores de soluciones CAD (BIM) para acceder a los datos a través de API y productos como Forge y ACC, o bien a eludir las limitaciones de los proveedores de CAD mediante el uso de costosos convertidores de SDK para la ingeniería inversa.
El acceso a los datos de su propio proyecto no debería requerir una clave especial, una tarifa de suscripción a una solución basada en la nube o un hechizo mágico en forma de solicitud de API.
El acceso a la información es un derecho, no un privilegio.
Tim Berners-Lee, inventor de la World Wide Web
El acceso a datos abiertos abrirá la próxima caja de Pandora para las empresas de construcción, lo que inevitablemente conducirá a la transformación de toda la industria de la construcción.
15. La uberización y los datos abiertos son una amenaza para el negocio de la construcción
En el futuro, los inversores y los clientes de financiación de la construcción se darán cuenta inevitablemente del valor de los datos abiertos y del análisis de datos históricos. Esto abrirá oportunidades para automatizar el cálculo de los cronogramas y los costos del proyecto, lo que permitirá un mejor control de los costos y una identificación más rápida de los costos excesivos. Por ejemplo, si los volúmenes de hormigón en el sitio se pueden comparar automáticamente con datos de proyecto MESH planos simples con metainformación estructurada sin el uso de CAD (BIM) y sus complejos núcleos geométricos, será inmediatamente obvio cómo se están sobrestimando las estimaciones.
Esta apertura y transparencia de los datos supone una amenaza para las empresas constructoras, que están acostumbradas a ganar dinero con procesos opacos e informes confusos, en los que se pueden esconder especulaciones y costes ocultos tras formatos y plataformas de datos complejos y cerrados. Por ello, es poco probable que las empresas constructoras estén interesadas en implementar plenamente los datos abiertos en sus procesos de negocio. Si los datos están disponibles y son fáciles de procesar para el cliente, se pueden comprobar automáticamente, lo que eliminará la posibilidad de sobreestimar los volúmenes y manipular las estimaciones.
La pérdida de control sobre los cálculos de volumen y de costes ya ha transformado otras industrias, permitiendo a los clientes alcanzar directamente sus objetivos. La digitalización y la transparencia de los datos han transformado muchos modelos de negocio tradicionales, como el de los taxistas con Uber, el de los hoteleros con Airbnb y el de los minoristas con Amazon, donde el acceso directo a la información y los pagos automatizados han reducido significativamente el papel de los intermediarios.
Figura 35. El negocio de la construcción se enfrentará pronto a los mismos procesos que hace 10 años tuvieron que afrontar los taxistas, los hoteleros y los vendedores.
Los inversores, clientes y bancos ya han empezado a exigir transparencia también en el sector de la construcción. El proceso de apertura y acceso sin restricciones a los datos es inevitable y, con el tiempo, los datos abiertos se convertirán en el nuevo estándar. Por ello, la implementación de formatos abiertos será una de las cuestiones más demandadas por los inversores, clientes, bancos y fondos de capital privado, es decir, los usuarios finales de los objetos construidos.
El movimiento del inversor, del cliente, desde la idea hasta el edificio terminado, en el futuro será como viajar con piloto automático, sin un conductor en forma de empresa constructora, promete ser independiente de la especulación y la incertidumbre.
Figura 36. Transición de la toma de decisiones basada en la opinión de profesionales importantes (HIPPO) al análisis de datos en la industria de la construcción: hoy y mañana
Los datos y procesos de todas las actividades económicas humanas no son diferentes a los que tienen que manejar los profesionales del sector de la construcción. La era de los datos abiertos y la automatización cambiará inevitablemente el negocio de la construcción, tal como ya lo ha hecho en la banca, el comercio, la agricultura y la logística. En estos sectores, el papel de los intermediarios y las formas tradicionales de hacer negocios están dando paso a la automatización y la robotización, sin dejar espacio para los sobreprecios injustificados y la especulación.
A largo plazo, las empresas constructoras, que hoy dominan el mercado al fijar estándares de precios y calidad del servicio, pueden perder su papel como intermediarios clave entre el cliente y su proyecto de construcción.
Los datos y procesos abiertos y estructurados proporcionarán a los clientes e inversores la base para realizar estimaciones precisas de los costes y plazos de los proyectos, eliminando la posibilidad de que las empresas de construcción especulen con datos opacos y formatos complejos. Esto supone tanto un reto como una oportunidad para que la industria reconsidere su papel y se adapte a un nuevo entorno en el que la transparencia y la eficiencia se convertirán en factores clave para el éxito. Pero ¿dónde deja esto a BIM en esta historia?
16. ¿BIM, openBIM, BIM Nivel 3 y noBIM existen realmente o son trucos de marketing?
Cuando hablamos de BIM, nos vienen a la mente imágenes de modelos 3D, herramientas de detección de colisiones y visualizadores de modelos en ACC. Pero si profundizamos, surge la pregunta: ¿qué es BIM realmente? ¿Es un conjunto de datos, parámetros y procesos o simplemente un eslogan de marketing? Para responder a esta pregunta, debemos ir más allá de las siglas y los conceptos promovidos por los proveedores de CAD y observar la esencia del trabajo con información de diseño: datos y procesos.
Cualquier proceso de negocio en el ámbito de la construcción no comienza con el trabajo en herramientas CAD (o BIM). En cualquier proceso de negocio, primero formamos los parámetros de la tarea y definimos los requisitos para los elementos futuros: especificamos una lista de entidades, sus características iniciales y valores límite. Esto se hace normalmente en forma de varias columnas de una tabla, base de datos o listas de pares clave-valor (1–2).
Y sólo sobre la base de estos parámetros iniciales, los objetos se crean de forma automática o manual en programas CAD/BIM mediante API (3-4), tras lo cual se comprueba de nuevo su conformidad con los requisitos iniciales (5-6). Este ciclo (definición, creación, verificación y corrección (2-6)) se repite hasta que la calidad de los datos alcance el nivel deseado para el sistema de destino (documentos, tablas o cuadros de mando) (7).
Figura 37. Ciclo de automatización de procesos para procesos de negocio en la industria de la construcción
Si consideramos el CAD (BIM) como una forma de transferir parámetros, que son conjuntos de claves y valores generados originalmente fuera del entorno CAD (1-2), entonces resulta obvio que trabajamos de hecho con una base de datos de parámetros (2-3, 5-6), que se complementa con diversas herramientas y en algún momento pasa de simples requisitos a un conjunto de elementos con parámetros, que en un programa CAD se manejan normalmente como una base de datos cerrada. Al abordar BIM a través del prisma de esta definición, encontramos principios similares a los utilizados en la analítica de datos, así como en los procesos ETL (extracción, transformación y carga de datos). Surge la pregunta: ¿cuál es la singularidad de BIM si no existen enfoques similares en otras industrias?
Durante los últimos 20 años, los proveedores de CAD han posicionado a BIM como algo más que una simple base de datos. En términos de marketing, BIM se vende como una herramienta paramétrica capaz de automatizar los procesos de diseño, modelado y gestión del ciclo de vida de los proyectos de construcción. Sin embargo, en realidad, BIM se ha convertido más en una herramienta para mantener a los usuarios en la plataforma de los proveedores que en un método conveniente para gestionar datos y procesos.
Figura 38. Comparación de flujos de trabajo de procesamiento de datos: enfoque CAD manual (BIM) sin procesamiento y flujo de trabajo automatizado con preprocesamiento de datos
Los proveedores han aislado eficazmente los datos CAD (BIM) de calidad dentro de sus plataformas, ocultándolos detrás de API, SDK y núcleos de geometría patentados. Esto ha privado a los usuarios de la capacidad de extraer, analizar y comunicar datos de forma independiente para eludir estos ecosistemas.
Hoy en día, la mayoría de los procesos de análisis de datos en la industria de la construcción son similares a los de otras industrias. Se trata de ciclos ETL (Extracción, Transformación, Carga) y análisis de datos típicos. En la banca, por ejemplo, los datos se extraen, se transforman en formatos comprensibles y se cargan en plataformas de BI para su visualización y análisis. En la construcción, se han realizado y se seguirán realizando las mismas acciones: extracción de datos de bases de datos CAD (BIM) (Extracción), normalización y estructuración, análisis posterior, transformación (Transformación) y carga a otros sistemas y bases de datos (Carga).
Con acceso completo a la base de datos CAD y utilizando herramientas de ingeniería inversa,podemos conseguir unoconjunto plano de entidades con atributos y exportarlas a cualquier formato abierto conveniente que contenga tanto geometría como atributos de elementos de diseño, similar a lo que se implementa en el proyecto SCOPE. Cuando los datos BIM se transforman en formatos fáciles de analizar (representaciones estructuradas de tablas, bases de datos, DWH, DL), los desarrolladores dejan de depender de esquemas de datos específicos y ecosistemas cerrados.
Figura 38. Comparación de flujos de trabajo de procesamiento de datos: enfoque CAD manual (BIM) sin procesamiento y flujo de trabajo automatizado con preprocesamiento de datos
Así es el futuro de la industria de la construcción: recopilar datos, analizarlos, validarlos y automatizar procesos con herramientas de análisis de datos.
La información es el petróleo del siglo XXI y el análisis es el motor de combustión interna.
Tal vez BIM (CAD) no sea el objetivo final, sino solo una etapa de la evolución. Cuando los profesionales de la construcción se den cuenta de que pueden trabajar directamente con datos, sin pasar por las herramientas CAD tradicionales, el término “BIM” se disolverá en un torrente de información. Comenzaremos a hablar de datos granulares o estructurados de proyectos de construcción, pero ya no será el BIM que conocemos hoy.
17. ¿Qué viene después? Formatos sencillos y herramientas fáciles de usar
La dirección clave del desarrollo puede ser la transición a soluciones abiertas e independientes, libres de SDK y motores de geometría propietarios. En lugar de intentar “modificar” el formato IFC, con el que sigue siendo difícil trabajar sin un conocimiento especial de las peculiaridades del formato y un motor de geometría especializado, la industria debería prestar atención a los formatos universales existentes que han demostrado su eficacia: MESH, OBJ, gLTF, DAE, FBX o USD para geometría, así como CSV, JSON, XML, XLSX, SQL, YAML para metadatos y parámetros.
El futuro de la industria de la construcción está ligado a la creación de herramientas sencillas y asequibles similares a las que surgieron en el campo de los gráficos 2D a finales de la década de 2010, tras dos décadas de dominio de Photoshop. La aparición de los formatos JPEG, PNG y GIF planos, libres de la lógica redundante de los motores internos de los editores 2D, ha propiciado el desarrollo de miles de soluciones de procesamiento de imágenes compatibles.
De la misma manera, la estandarización y simplificación de los formatos 3D y de la metainformación estimulará la aparición de muchas herramientas cómodas e independientes para trabajar en proyectos de construcción. El abandono de la lógica compleja de los “núcleos de proveedores” y el paso a formatos universales y abiertos crearán las condiciones para un trabajo más flexible y eficiente, así como para un acceso abierto a los datos para todos los participantes en el proceso de construcción.
Figura 39. Nivel de madurez CAD/BIM: desde datos no estructurados a datos totalmente estructurados y repositorios.
Hay proyectos prometedores en la comunidad de código abierto que pueden servir como ejemplos de desarrollo de solucionadores geométricos ligeros:Resolver el espaciocon potencial para funcionar en el navegador,Web-CAD.orgsobre JavaScript, varios editores CSG gratuitos.Se debe prestar especial atención a la plataforma Unity, que proporciona una base preparada para crear herramientas complejas con la capacidad de personalizar la representación y agregar la funcionalidad necesaria.En mi2021ejemplo,El motor del programa CAD basado en navegador de UnityNota CADFue rediseñado con su propio solucionador de geometría para que coincida lo más posible con la funcionalidad del SketchUp en línea gratuito.El resultado es un producto ligero y gratuito.y de código abiertoproductoque se ejecuta rápidamente en cualquier servidor.
Figura 40. Ejemplo de BimCADOnline de una solución en línea de código abierto con su propio solucionador geométrico
El principio fundamental del desarrollo de la industria no debe ser la creación de nuevos formatos, sino el uso eficaz y el perfeccionamiento de las soluciones existentes. Es importante apoyarse en comunidades internacionales comoOsArchyFreeCAD, y apoyar a los equipos que desarrollan núcleos de geometría abierta.
Para aquellos que necesitan trabajar con geometría BREP, núcleos de geometría de código abierto comoOCCyOGGpuede desempeñar un papel clave. Y para tareas donde la geometría MESH es suficiente,CGAL, Malla abiertayBiblioteca de mallaSerá una solución prometedora. Utilice SDK de ingeniería inversa de empresas comoAlianza de Diseño Abierto, Intercambiador CADoAROSpara recuperar y escribir datos en variosCANALLAy formatos MCAD. Estos SDK se han creado para brindar a los desarrolladores acceso igualitario a los datos y garantizar que todos puedan desarrollar soluciones CAD y MCAD al nivel de los principales desarrolladores CAD (BIM).
Figura 41 OpenDWG. El objetivo de la Alianza es nivelar el campo de juego para todos los proveedores de CAD, independientemente de su relación con ADSK.
Combinadas con los modelos LLM, estas herramientas mejorarán enormemente la eficiencia de los procesos de creación, transformación y exportación de datos a los sistemas de destino.
18. Aparición de LLM y ChatGPT en los procesos de datos del proyecto
Además del desarrollo de formatos abiertos y herramientas universales, los modelos de lenguaje de gran tamaño (LLM) como LLaMA, ChatGPT, Gemini y Claude están revolucionando la industria del procesamiento de datos. Estas tecnologías soncambiando fundamentalmente la formaLos datos del proyecto se manejan y analizan, haciendo que el procesamiento y la automatización sean accesibles para todos los involucrados en el proceso de construcción.
Si antes se accedía a la información exclusivamente a través de API complejas e interfaces SDK que requerían habilidades de programación especiales, ahora es posible interactuar con los datos en lenguaje natural.
Dentro de unos años, inevitablemente se producirá una democratización del acceso a los datos. Los ingenieros, gerentes y planificadores comunes podrán obtener la información necesaria de los datos del proyecto en formatos estructurados simplemente formulando consultas en lenguaje común. Por ejemplo, será suficiente preguntar en el chat:“Mostrar en una tabla con agrupación por tipo todos los muros con un volumen de más de 10 metros cúbicos”, — y LLM convertirá independientemente esta consulta en una consulta SQL o Pandas, transformando los datos estructurados del proyecto mediante la agrupación en el formato deseado de una tabla, un gráfico o un documento terminado.
Cada día que pasa, la industria de la construcción oirá hablar más de datos estructurados granulares, DataFrames y bases de datos en columnas. Los DataFrames bidimensionales unificados formados a partir de varias bases de datos y formatos CAD (BIM) serán el combustible perfecto para las herramientas analíticas modernas. Y herramientas como Pandas y bibliotecas similares para trabajar con tablas bidimensionales y bases de datos en columnas son ideales para su uso en LLM debido a sus potentes capacidades de procesamiento de datos e indexación eficiente. Estos datos no requieren una comprensión de los formatos de esquema y se convierten en una fuente ideal para RAG, LLM y ChatGPT.
El proceso de automatización en sí se simplificará significativamente: en lugar de estudiar API de productos cerrados y escribir scripts complejos en Python, C# o JavaScript para analizar o transformar parámetros, ahora será suficiente formular la tarea en forma de un conjunto de comandos de texto separados que se integrarán en el proceso de flujo de trabajo o canalización adecuado para el lenguaje de programación adecuado.
Figura 42. Pasar de la programación a la creación de consultas en el LLM para crear un proceso Pipeline
Ya no es necesario esperar nuevos productos, formatos, complementos o actualizaciones de los proveedores de herramientas CAD (BIM). Los ingenieros y constructores podrán trabajar de forma independiente con los datos mediante herramientas sencillas, gratuitas y fáciles de entender con los chatbots de LLM.
Las modernas herramientas de análisis de datos, combinadas con formatos de datos abiertos, crearán un nuevo paradigma de trabajo en la industria de la construcción, donde lo principal no será la posesión de un determinado software y la comprensión de su API, sino la capacidad de formular y parametrizar tareas de manera efectiva y analizar rápidamente los datos obtenidos.
En lugar de una conclusión
La situación de la interoperabilidad y la multiplataforma en el sector de la construcción muestra claramente los problemas subyacentes asociados a la transferencia y el uso de datos entre diferentes sistemas CAD (BIM). Un claro ejemplo de ello es ADSK, que promueve activamente el formato IFC abierto, pero no es capaz de garantizar la correcta exportación de sus propios productos y tiene que recurrir al SDK de ingeniería inversa de OpenDesignAlliance, una organización que se creó originalmente en 1998.Para contrarrestarADSKEl monopolio deParadójicamente, esta situación obliga a todos los actores de la industria a utilizar SDK similares para extraer y adaptar los datos de las soluciones CAD de la competencia para sus plataformas, lo que socava de manera efectiva la idea de interoperabilidad entre plataformas para la que se creó el formato de interoperabilidad IFC.
El formato IFC, que pretendía ser un puente universal entre los distintos sistemas CAD (BIM), en realidad sirve como indicador de problemas de compatibilidad entre núcleos geométricos de distintas plataformas CAD, de forma similar al formato STEP del que surgió originalmente. A pesar de la activa promoción del formato por parte de laConstrucción inteligenteEn la organización, los principales esfuerzos se centran en la estandarización de la geometría (que requiere un núcleo geométrico unificado, que aún no existe), y en la unificación de la semántica y las ontologías para la industria de la construcción. Sin embargo, estos esfuerzos reflejan las ambiciones no realizadas del concepto de Internet Semántica, donde las expectativas superaron con creces la realidad.
Figura 43. Geometría e información en los procesos de construcción: desde sistemas CAD y BIM complejos hasta datos simplificados para análisis
Las particularidades del sector agravan este problema. El sector de la construcción, que tradicionalmente va entre 10 y 20 años por detrás de otros sectores en el dominio de las nuevas tecnologías, corre el riesgo de repetir este camino. Si en TI los fracasos de la web semántica se compensaron con la aparición de nuevas tecnologías (big data, IoT, aprendizaje automático, realidad aumentada y virtual), el sector de la construcción no tiene esas razones.
Sin embargo, también hay ejemplos aislados de enfoques alternativos. Züblin, con su proyecto SCOPE, demuestra cómo es posible ir más allá de la lógica clásica de los sistemas CAD (BIM). En lugar de intentar subordinar a IFC o confiar en núcleos geométricos propietarios, utilizan API y SDK de ingeniería inversa para extraer datos de varios programas CAD, convertirlos en formatos neutrales como OBJ o CPIXML basados en el núcleo de código abierto OpenCascade y luego aplicarlos a cientos de procesos comerciales de empresas de construcción y diseño. Sin embargo, a pesar de lo progresista de la idea, estos proyectos siguen siendo parte de ecosistemas cerrados que reproducen la lógica de las soluciones de un solo proveedor. Como resultado, la industria de la construcción está atrapada una vez más en una situación en la que los estándares multiplataforma como IFC no cumplen su misión y las iniciativas locales solo mitigan parcialmente el problema.
Y es muy probable que los proveedores de CAD logren una vez más desplazar la discusión sobre el acceso a datos abiertos hacia “nuevos” conceptos, formatos y alianzas que, como BIM y openBIM, servirán principalmente como herramienta para mantener a los usuarios en ecosistemas propietarios, lo que una vez más detendrá el crecimiento de la productividad en una industria ya improductiva, ya que los recursos se dirigirán no a simplificar y optimizar procesos, sino a mantener el control de los ecosistemas y atraer usuarios al nuevo concepto.
Figura 44. Durante los últimos 30 años, las tecnologías CAD (BIM) no han logrado aumentar la productividad en la industria de la construcción.
El objetivo de este análisis no es criticar los enfoques existentes, sino iniciar un debate sobre la cuestión principal: cómo aumentar la productividad en la industria de la construcción y si es posible en principio. Tengo un profundo respeto por los desarrolladores de soluciones CAD (BIM) y ADSK, así como por los participantes y miembros deConstrucción inteligenteSin embargo, tal vez sea el momento de dejar de esperar a que los nuevos conceptos surjan de los proveedores de software y centrarse en el desarrollo independiente. Al liberarse de los problemas de acceso a los datos, la industria podrá pasar a herramientas modernas y fáciles de usar para trabajar con los datos y analizarlos. Esto le permitirá avanzar en la dirección que Samuel Geisbergseñalóa finales de la década de 1980.
El software CAD/CAM tradicional limita de forma poco realista la posibilidad de realizar cambios económicos al comienzo mismo del proceso de diseño. El objetivo es crear un sistema que sea lo suficientemente flexible como para animar al ingeniero a considerar fácilmente diferentes diseños. Y el coste de realizar cambios en el diseño debería ser lo más cercano a cero posible.
Este es el comienzo de un debate sobre la transformación de la industria. Solo si solucionamos los problemas de acceso a los datos podremos avanzar hacia la exploración de los procesos empresariales y su automatización.
📈 Los datos y formatos abiertos se convertirán inevitablemente en un estándar en la industria de la construcción; es solo cuestión de tiempo. Esta transición se acelerará si todos difundimos información sobre formatos abiertos, herramientas de acceso a bases de datos y SDK para ingeniería inversa. Todos y cada uno de ustedes pueden ayudar en este proceso. Si la información que lee le resulta útil, compártala con sus colegas.
Si desea mantenerse al día con nuevas actualizaciones y artículos, suscríbase a los boletines informativos en elConstrucción basada en datossitio web o suscribirse enLinkedInyMedio.
Este documento analiza temas generales en el campo de la construcción y los procesos de datos, haciendo referencia a prácticas históricas y actuales de la industria. Todas las marcas comerciales y marcas registradas son propiedad de sus respectivos dueños, y este texto no está afiliado ni respaldado por ningún propietario de marca comercial. El contenido de este documento se proporciona con fines informativos y no constituye asesoramiento legal o técnico.
- Aviso legal de marca registrada:
Todos los nombres de productos, logotipos y marcas mencionados en este documento son propiedad de sus respectivos dueños. El uso de estos nombres, logotipos o marcas no implica su aprobación.
2.Declaración de no infracción:
Este documento tiene fines meramente informativos. El contenido presentado no pretende infringir ni reclamar la propiedad de ninguna marca registrada, patente o propiedad intelectual.
3.Aviso de uso justo:
Este material se proporciona de conformidad con los principios de uso justo con fines educativos, de investigación e informativos. El contenido se basa en información disponible públicamente y no pretende representar ni reproducir conocimientos exclusivos.
4.Reconocimiento de derechos de autor:
Algunas secciones de este documento hacen referencia a materiales de terceros y se les da el crédito correspondiente. Si tiene alguna inquietud sobre derechos de autor, comuníquese con nosotros para abordarla de manera apropiada.
5. Declaración de atribución:
Los marcos, formatos o herramientas específicos mencionados se atribuyen a sus respectivos autores u organizaciones. Su inclusión tiene como finalidad el análisis y los comentarios.
Otros artículos sobre estos temas:
📰 Guerras de lobby y desarrollo BIM. Todas las partes
📰 El libro “DataDrivenConstruction. Navegando la era de los datos en la industria de la construcción”
