En el dinámico mundo de la construcción y el diseño, la necesidad de una comunicación eficiente y precisa entre los diversos actores involucrados en un proyecto ha sido siempre un desafío constante. Industry Foundation Classes (IFC) surgió como una respuesta a esta necesidad, proporcionando un estándar abierto para el intercambio de datos en el sector de la construcción. Sin embargo, a medida que la industria avanza hacia una mayor digitalización y complejidad, IFC también debe evolucionar para mantenerse relevante y efectivo.
Este artículo explora el fascinante viaje de IFC hacia su quinta iteración, IFC5, un desarrollo que promete revolucionar la forma en que concebimos y utilizamos los esquemas de datos en la industria de la construcción. Desde sus humildes comienzos hasta las discusiones actuales sobre su futuro, examinaremos cómo IFC5 está siendo moldeado por las necesidades cambiantes de la industria y los avances tecnológicos.
Este artículo está disponible en inglés en este enlace.
Contexto y antecedentes de IFC
Evolución de IFC hasta la versión 4
IFC ha recorrido un largo camino desde su concepción inicial. Desarrollado por buildingSMART International [6], anteriormente conocidos como International Alliance for Interoperability (IAI), IFC se ha convertido en el estándar de facto para el intercambio de datos en Building Information Modelling.
El legado de STEP en IFC [1] [2]
En sus inicios, IFC se basó en el formato STEP (Standard for the Exchange of Product Model Data), un estándar internacional para la representación y el intercambio de datos de modelos de producto. STEP proporcionó técnicas avanzadas de modelado que permitieron un intercambio de datos eficiente y un almacenamiento optimizado en archivos. Esta elección fue estratégica, ya que STEP era adecuado para las necesidades de intercambio de datos basados en archivos prevalentes en ese momento.
Sin embargo, el uso de estas técnicas avanzadas también resultó en un esquema complejo. La estructura monolítica y la dependencia de tecnologías específicas de STEP hicieron que el esquema de IFC fuera difícil de implementar y expandir. Además, esto condujo a tamaños de archivo grandes y a una escalabilidad limitada, lo que afectó la adopción y efectividad de IFC en proyectos más grandes y complejos.
Las versiones de IFC hasta IFC4
La evolución de IFC ha sido gradual pero constante:
- IFC1.0 (1997): La primera versión, que sentó las bases del esquema y utilizó STEP como su base tecnológica.
- IFC2x (2000-2003): Introdujo mejoras significativas en la estabilidad y la cobertura del esquema, pero manteniendo la dependencia de STEP.
- IFC2x3 (2006): Ampliamente adoptada, esta versión se convirtió en un hito importante, aunque seguía heredando las limitaciones del enfoque basado en STEP. [3]
- IFC4 (2013): La versión actual, que incluye mejoras en la representación geométrica y el soporte para nuevos dominios, pero que aún conserva gran parte de su legado de STEP. [4]
IFC4, con sus subversiones 4.3 [5] y próximamente 4.4 [6], representa el estado actual del arte en intercambio de datos BIM. Sin embargo, a pesar de sus avances, la industria ha comenzado a reconocer las limitaciones inherentes debido a su dependencia continua de STEP. La complejidad del esquema, las dificultades en la implementación y las restricciones en la interoperabilidad han destacado la necesidad de una evolución fundamental en el enfoque de IFC.
La hoja de ruta técnica de buildingSMART
En 2020, buildingSMART International, bajo el liderazgo de Léon van Berlo [7], presentó una nueva hoja de ruta técnica [8] que marcaría el rumbo no solo para el desarrollo inmediato de IFC, sino también para su futuro a largo plazo. Esta hoja de ruta reconoce la necesidad de una transformación significativa en la forma en que IFC aborda la representación y el intercambio de datos.
Una de las decisiones clave fue moverse hacia un esquema independiente del lenguaje, liberando a IFC de su dependencia con STEP. Esto permitiría que IFC pudiera representarse en múltiples formatos, como XML, JSON, RDF e incluso formatos binarios como HDF5. Al adoptar un enfoque más agnóstico en cuanto al formato, IFC podría ser más adaptable y accesible para una gama más amplia de usuarios y aplicaciones de software.
La visión presentada en esta hoja de ruta no se limita a mejoras incrementales, sino que contempla una reimaginación fundamental de IFC. Se reconoce que los desafíos actuales y futuros de la industria requieren un enfoque más flexible, escalable y adaptable que el que puede ofrecer la estructura actual basada en STEP.
Desafíos y limitaciones de IFC4
Complejidad y extensibilidad
Uno de los principales desafíos que enfrenta IFC4 es su creciente complejidad, en parte debido a su herencia de STEP. La estructura monolítica y las técnicas avanzadas de modelado utilizadas hacen que el esquema sea difícil de manejar y extender. Esta complejidad no solo afecta a los desarrolladores de software que implementan IFC, sino también a los usuarios finales que deben navegar por un sistema cada vez más intrincado.
La dependencia de tecnologías específicas de STEP ha limitado la capacidad de IFC para adaptarse a nuevas necesidades sin comprometer su integridad. Incorporar nuevos conceptos o relaciones a menudo requiere cambios significativos, lo que puede llevar a incompatibilidades entre versiones y dificultades en la adopción de nuevas características.
Colaboración y autoría distribuida
Otro desafío importante es la creciente necesidad de colaboración en tiempo real y autoría distribuida en los proyectos de construcción. IFC4, aun siendo excelente para el intercambio de datos basado en archivos, no fue diseñado con estas capacidades en mente. La estructura rígida y monolítica heredada de STEP dificulta la colaboración distribuida y la integración en entornos más dinámicos y conectados.
Esta limitación se hace especialmente evidente en proyectos grandes y complejos, donde la coordinación entre diferentes disciplinas y la gestión de cambios en tiempo real son cruciales. La falta de flexibilidad en el esquema actual obstaculiza la eficiencia y puede conducir a errores en el proceso de diseño y construcción.
Estos desafíos y limitaciones han sido el catalizador para repensar fundamentalmente la estructura y los objetivos de IFC, dando lugar a las primeras conceptualizaciones de lo que se convertiría en IFC5.
Conceptualización inicial de IFC5
De COINS a ECS: conceptualización temprana de IFC5
El camino hacia IFC5, buscando superar las limitaciones de versiones anteriores, no surgió en el vacío. Dentro de los Países Bajos, existía un precursor de este esfuerzo global llamado COINS. Este estándar neerlandés, aunque finalmente fue reemplazado, tenía como objetivo abordar las complejidades del intercambio de información digital en proyectos de construcción. COINS buscaba tender puentes entre diversos interesados que utilizaban diferente software y formatos de datos, reconociendo la necesidad crítica de interoperabilidad dentro de la industria. Aunque COINS finalmente dio paso a estándares más nuevos, su objetivo central se resumía en: facilitar el intercambio fluido de datos de construcción, sentando bases importantes para desarrollos futuros, incluida la conceptualización de IFC5. Las limitaciones encontradas por COINS, como su adopción restringida y el surgimiento de estándares internacionales más avanzados, probablemente causaron la futura trayectoria de desarrollo de IFC5. La exploración subsiguiente del Entity Component System (ECS), que detallaremos en las siguientes secciones, como una solución potencial para IFC5 refleja una continuación de estos esfuerzos, aunque a una escala más amplia y globalmente enfocada.
El potencial del Entity Component System (ECS) [9]
La búsqueda de una solución a los desafíos presentados por IFC4 llevó a los desarrolladores a explorar nuevos paradigmas de modelado de datos. Una de las propuestas más prometedoras fue la adopción del Entity Component System (ECS), un patrón de diseño originario de la industria de los videojuegos.
El ECS propone una estructura de datos fundamentalmente diferente:
- Entidades: Identificadores únicos que representan objetos en el modelo.
- Componentes: Conjuntos de datos que describen aspectos específicos de una entidad.
- Sistemas: Lógica que opera sobre entidades con componentes específicos.
Esta estructura ofrece varias ventajas potenciales para IFC5:
- Flexibilidad: Permite añadir o modificar componentes sin alterar la estructura fundamental del objeto.
- Granularidad: Facilita el acceso y la manipulación de datos específicos sin necesidad de procesar el objeto completo.
- Eficiencia: Mejora el rendimiento en operaciones que solo requieren ciertos tipos de datos.
- Colaboración distribuida: Permite que diferentes disciplinas contribuyan con datos específicos a un mismo objeto sin conflictos.
Primera propuestas y experimentos
Las primeras exploraciones de ECS para IFC5 se centraron en cómo esta estructura podría abordar las limitaciones de IFC4:
- Manejo de relaciones tipo-ocurrencia: Se propuso un sistema de "prefijado de ID" para mantener la relación entre tipos y ocurrencias de objetos, permitiendo herencia de propiedades y sobreescrituras específicas.
- Geometría simplificada: Se consideró el uso de mallas triangulares como representación geométrica principal, con metadatos adicionales para preservar la información semántica.
- Serialización flexible: Se exploraron formatos como JSON para representar la estructura ECS, buscando un equilibrio entre legibilidad humana y eficiencia computacional.
- Composición y herencia: Se investigaron mecanismos para permitir la composición de objetos complejos y la herencia de propiedades, manteniendo la flexibilidad del ECS.
Estos experimentos iniciales demostraron el potencial del ECS para abordar muchos de los desafíos de IFC4, pero también revelaron nuevas complejidades y áreas que requerían mayor investigación.
Desarrollo actual de IFC5 (2024)
El giro hacia Universal Scene Description (USD) [10]
A medida que avanzaba el desarrollo de IFC5, la comunidad de buildingSMART comenzó a prestar atención a otra tecnología emergente: Universal Scene Description (USD).
Antecedentes del USD y su Papel en la Industria de la Construcción
USD (Universal Scene Description), desarrollado originalmente por un importante estudio de animación (Píxar), es un formato de archivo diseñado para flujos de trabajo colaborativos en 3D, especialmente en gráficos por computadora y efectos visuales. Su creciente popularidad en la industria de la construcción proviene de su simplicidad, eficiencia en el manejo de datos 3D complejos y capacidad para soportar flujos de trabajo colaborativos. A diferencia de los formatos tradicionales como IFC, que están arraigados en tecnologías más antiguas y pueden ser complejos de gestionar, USD ofrece una estructura más plana y accesible que se adapta mejor al procesamiento y análisis de datos modernos.
Varias empresas tecnológicas líderes e instituciones están desempeñando papeles significativos en la integración de USD en la industria de la construcción. Tres importantes corporaciones tecnológicas han formado una alianza con el objetivo de promover USD como un estándar para el intercambio de datos y la colaboración. Dos destacados proveedores de software de construcción, que son miembros clave de buildingSMART, también se han unido a esta alianza. Esto sugiere un posible cambio en la industria hacia USD, aunque buildingSMART no se ha comprometido oficialmente a integrar USD en futuras versiones de IFC. Este cambio está impulsado por el deseo de una gestión de datos más eficiente y potencialmente influenciado por los intereses estratégicos de los principales proveedores de software, que ven USD como una forma de unificar datos y potencialmente optimizar sus ecosistemas.
USD ofrece varias características que se alinean con los objetivos de IFC5:
- Composición de datos: USD permite combinar datos de múltiples fuentes de manera no destructiva, facilitando la colaboración.
- Estructura jerárquica: Utiliza un sistema de "prims" (primitivas) organizados en una estructura de árbol, similar a la jerarquía de objetos en IFC.
- Esquemas extensibles: Proporciona mecanismos para definir y extender esquemas de datos de manera flexible.
- Rendimiento optimizado: Diseñado para manejar conjuntos de datos masivos y complejos.
El interés en USD llevó a un replanteamiento de la dirección de IFC5, explorando cómo los conceptos de USD podrían integrarse o inspirar el desarrollo futuro.
Explorando nuevos enfoques de serialización
Paralelamente al interés en USD, se ha continuado la exploración de formatos de serialización más eficientes y flexibles para IFC5. Algunas de las áreas de investigación incluyen:
- USD JSON: Una representación de USD en formato JSON, buscando combinar la flexibilidad de USD con la familiaridad y facilidad de uso de JSON.
- Formatos binarios optimizados: Investigación en formatos que puedan manejar eficientemente grandes volúmenes de datos geométricos y semánticos.
- Serialización incremental: Desarrollo de métodos para transmitir y actualizar solo los cambios en un modelo, en lugar de todo el conjunto de datos.
- Integración con estándares existentes: Exploración de cómo IFC5 podría interoperar más fácilmente con formatos como glTF para geometría o BCF para comunicación.
Estas exploraciones buscan no solo mejorar la eficiencia técnica de IFC, sino también facilitar su adopción en un ecosistema tecnológico más amplio.
Retos y oportunidades en el desarrollo de IFC5 [12]
Representación geométrica y semántica
Uno de los mayores desafíos en el desarrollo de IFC5 es encontrar el equilibrio adecuado entre la simplicidad de la representación geométrica y la riqueza de la información semántica. El enfoque en mallas triangulares como representación geométrica principal ofrece ventajas en términos de rendimiento y compatibilidad, pero plantea preguntas sobre cómo preservar la intención del diseño y la información paramétrica.
Simplificación de la definición geométrica en IFC5
La adopción de las características de USD en IFC5 ha abierto la puerta a la simplificación de la definición geométrica. Una de las ventajas clave de USD es su capacidad para manejar la composición, permitiendo que las ocurrencias de objetos hereden datos de un elemento "típico". Esto significa que la geometría de un objeto repetido no necesita redefinirse múltiples veces, sino que puede heredarse de una sola fuente.
Esta composición se logra al trasladar la idea de herencia de ocurrencias a un nivel más fundamental dentro del sistema de serialización o biblioteca. En lugar de tratarla como otro componente, se convierte en un comportamiento inherente del sistema, lo que permite una representación más eficiente de geometrías repetidas.
Además, USD introduce un lenguaje de esquemas que define entidades y sus componentes asociados, asegurando que solo los componentes relevantes se apliquen a una entidad específica. Por ejemplo, los materiales no se aplicarían a los conjuntos de propiedades, evitando asociaciones de datos ilógicas.
La simplificación también implica migrar desde las definiciones geométricas procedimentales y complejas actuales en IFC a un enfoque centrado en mallas triangulares, una representación geométrica fundamental en USD. Esto elimina las dependencias profundas y las intrincadas operaciones booleanas que hacen que analizar y modificar la geometría en IFC sea complicado.
Aunque las mallas serían la representación primaria, existe la posibilidad de superponer información semántica adicional sobre ellas. Esto permitiría representar conceptos como extrusiones, planos de corte y vaciados de manera más simplificada y generalizada.
Este enfoque simplificado de la definición geométrica, junto con las capacidades de composición de USD, aborda la preocupación sobre las definiciones geométricas repetitivas. Al definir un elemento típico y permitir que las instancias hereden sus propiedades geométricas, IFC5 podría reducir la redundancia y mejorar la eficiencia en el manejo de modelos complejos.
No obstante, al simplificar la geometría, es fundamental garantizar que no se sacrifiquen aspectos importantes de la intención del diseño. La capacidad de representar detalles paramétricos y semánticos sigue siendo esencial para muchas aplicaciones, por lo que IFC5 deberá encontrar formas de mantener esta información, posiblemente mediante metadatos adicionales o capas semánticas sobre las mallas básicas.
Estandarización e implementación de software
La transición de un enfoque basado en STEP a uno independiente del lenguaje presenta desafíos significativos para la estandarización y la implementación en software. Los desarrolladores necesitarán adaptar sus herramientas y flujos de trabajo para trabajar con estas nuevas estructuras de datos.
Oportunidades clave incluyen:
- Desarrollo de herramientas y bibliotecas de referencia: Facilitar la implementación de IFC5 en software mediante recursos y documentación detallada.
- Programas de certificación y pruebas: Garantizar la interoperabilidad entre diferentes implementaciones a través de estándares de calidad y conformidad.
- Colaboración con la industria: Trabajar estrechamente con desarrolladores y usuarios finales para identificar desafíos y necesidades, asegurando que IFC5 sea práctico y útil.
El futuro de IFC5: Perspectivas y expectativas
Mirando hacia el futuro, IFC5 tiene el potencial de transformar cómo se gestiona la información en la industria de Arquitectura, Ingeniería y Construcción. Sin embargo, es crucial reconocer que esta transformación debe estar arraigada en una comprensión profunda y una utilización efectiva de la información semántica. Algunas perspectivas y expectativas clave, considerando el papel vital de la semántica, incluyen:
- Integración más profunda con otras disciplinas preservando la riqueza semántica: IFC5 debería facilitar una integración perfecta con campos como el geoespacial, la gestión de instalaciones y la planificación urbana, pero esta integración no debe realizarse a expensas de la riqueza semántica. El desafío radica en desarrollar mecanismos de mapeo que permitan el intercambio de información semántica significativa entre diferentes dominios, asegurando la consistencia y la interoperabilidad de los datos. Por ejemplo, al integrarse con datos geoespaciales, IFC5 no solo debería intercambiar representaciones geométricas de edificios, sino también transmitir información semántica sobre su función, ocupación y otras propiedades relevantes.
- Mejora del soporte para gemelos digitales con interoperabilidad semántica: La estructura más flexible y eficiente de IFC5 puede hacerla más adecuada para aplicaciones de gemelos digitales en tiempo real. Sin embargo, el éxito de los gemelos digitales depende de la capacidad de acceder, analizar y visualizar no solo la geometría, sino también la información semántica asociada con los componentes de los edificios. Esto requiere que IFC5 proporcione mecanismos sólidos para representar y consultar relaciones semánticas, clasificaciones y propiedades, garantizando que los gemelos digitales puedan aprovechar toda la riqueza de la información de construcción.
- Facilitando la inteligencia artificial y el aprendizaje automático a través de estructuras de datos semánticos: Una estructura de datos más granular y semánticamente rica en IFC5 puede permitir análisis y optimización avanzados utilizando inteligencia artificial y aprendizaje automático. Los algoritmos de IA se basan en datos estructurados y etiquetados semánticamente para identificar patrones, generar perspectivas y hacer predicciones. Por lo tanto, IFC5 debería priorizar el desarrollo de un modelo de datos que facilite el etiquetado y estructuración semántica, haciéndolo fácilmente utilizable por aplicaciones de IA para tareas como la verificación automatizada de cumplimiento normativo o regulatorio, análisis de rendimientos y mantenimiento predictivo.
- Mayor adopción por parte de la industria impulsada por la claridad y usabilidad semántica: Si IFC5 logra sus objetivos de simplicidad y flexibilidad, podría ver una adopción más amplia en la industria, incluso en áreas donde IFC4 ha tenida ya sus desafíos. Sin embargo, la simplicidad no debe equivaler a una reducción de la información semántica. IFC5 debe encontrar un equilibrio entre la facilidad de implementación y la riqueza semántica, asegurando que el modelo de datos siga siendo lo suficientemente completo y expresivo para satisfacer las diversas necesidades de la industria AEC. Esto implica desarrollar formas claras e intuitivas de representar información semántica, haciéndola accesible y utilizable por una gama más amplia de partes interesadas.
- Evolución continua guiada por las necesidades semánticas cambiantes de la industria: Es probable que IFC5 evolucione para adaptarse a las cambiantes necesidades de la industria y los avances tecnológicos. Esta evolución debe incluir un enfoque en la incorporación de nuevos tipos de información semántica y la adaptación de estructuras de datos existentes para acomodar tecnologías emergentes y casos de uso. Por ejemplo, a medida que la industria se mueve hacia un enfoque más basado en datos, IFC5 podría necesitar incorporar información semántica relacionada con datos de sensores, rendimiento de edificios y comportamiento del usuario, asegurando que el estándar siga siendo relevante y valioso en el futuro.
En conclusión, mientras que las expectativas propuestas para IFC5 son prometedoras, deben ser vistas a través del lente de la información semántica. Deberíamos destacar la importancia de los datos semánticos para lograr los objetivos de IFC y apoyar el movimiento de la industria hacia un futuro más basado en datos y automatizado. El éxito de IFC5 dependerá de su capacidad para no solo simplificar y agilizar ciertos aspectos, sino también mantener y mejorar la riqueza semántica del modelo de datos, permitiendo una representación verdaderamente integral e perspicaz de la información de construcción.
Conclusiones finales
El desarrollo de IFC5 representa un momento crucial en la evolución de los estándares de intercambio de información en la industria AEC. Al abordar las limitaciones de las versiones anteriores y explorar nuevos paradigmas como ECS y conceptos de USD, IFC5 promete ofrecer un estándar más flexible, eficiente y adaptable a las necesidades futuras de la industria. La transición desde una dependencia en STEP hacia un esquema independiente del lenguaje constituye un paso significativo que ampliará la accesibilidad y usabilidad de IFC, permitiendo que una gama más amplia de aplicaciones de software interactúen con el estándar, fomentando así una mayor interoperabilidad y colaboración en toda la industria.
Sin embargo, es fundamental reconocer que la adopción global de IFC4.x, y el camino hacia IFC5 no está exento de desafíos significativos. La implementación de nuevos paradigmas y tecnologías requerirá un esfuerzo concertado por parte de los desarrolladores de software, los profesionales de la industria y los organismos de estandarización. Los recientes éxitos alcanzados con IFC 4.3 y los prometedores avances que se anticipan en IFC 4.4, especialmente en áreas como túneles y aspectos geotécnicos, demuestran la vitalidad y relevancia continua de la serie 4.x, una base sólida que debe ser protegida y valorada.
La transición hacia IFC5 debe entenderse como una evolución natural más que como una revolución disruptiva, donde mantener el equilibrio entre innovación y estabilidad resulta fundamental. Las organizaciones que actualmente están invirtiendo en implementaciones IFC4.x deben sentirse seguras de que sus esfuerzos no serán en vano, ya que estas implementaciones constituirán la base sobre la cual se construirá el futuro de IFC. La colaboración continua y la retroalimentación de todas las partes interesadas seguirán siendo cruciales para garantizar que IFC5 cumpla con sus objetivos sin causar disrupciones innecesarias en los flujos de trabajo existentes.
En última instancia, el éxito de IFC5 dependerá no solo de sus méritos técnicos, sino también de su capacidad para construir sobre los logros de IFC4.x, manteniendo la confianza de la industria y asegurando una continuidad en el desarrollo de la infraestructura digital de la construcción. Con un enfoque cuidadoso y colaborativo, IFC5 tiene el potencial de sentar las bases para una industria AEC más integrada, eficiente e innovadora en las próximas décadas, sin comprometer los avances y las inversiones realizadas hasta la fecha. Este equilibrio entre innovación y estabilidad será fundamental para garantizar una transición exitosa hacia la próxima generación de estándares de intercambio de información en la construcción.
Autor
David Delgado Vendrell es el Coordinador Técnico de buildingSMART Spain.
Arquitecto y Consultor de DDV Solutions. Colabora como docente en varios programas educativos de BIM a nivel nacional e internacional.
Participa en la Comisión "Construïm el Futur" en Catalunya, representando a buildingSMART Spain, así como en el comité UNE CTN332.
Es coautor del sistema de clasificación BIM "GuBIMclass".
Referencias Bibliográficas
[1] International Organization for Standardization, "ISO 10303-21:2016 Industrial automation systems and integration — Product data representation and exchange — Part 21: Implementation methods: Clear text encoding of the exchange structure", ISO, [En línea]. Disponible en: https://www.iso.org/standard/63141.html. [Accedido: 2016]
[2] International Organization for Standardization, "ISO 10303: STEP Standards", ISO, Geneva, Switzerland, 2016.
[3] buildingSMART International, "IFC2x3 TC1 Documentation", buildingSMART Standards, [En línea]. Disponible en: https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/. [Accedido: 2024]
[4] buildingSMART International, "IFC4 Add2 TC1 Documentation", buildingSMART Standards, [En línea]. Disponible en: https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/. [Accedido: 2024]
[5] buildingSMART International, "IFC4.3 Documentation", buildingSMART Standards, [En línea]. Disponible en: https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/. [Accedido: 2024]
[6] buildingSMART International, "IFC 4.4 - dev: Potential extension of 4.3. Adding additional functionality. Currently in planning phase", buildingSMART Technical, [En línea]. Disponible en: https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/. [Accedido: 2024]
[7] L. van Berlo et al., "BIM Quickscan: Benchmark of BIM Performance in the Netherlands", en Proc. CIB W78 2012: 29th International Conference, 2012. [En línea]. Disponible en: https://itc.scix.net/pdfs/w78-2012-Paper-30.pdf
[8] buildingSMART International, "Technical Roadmap", buildingSMART, [En línea]. Disponible en: https://www.buildingsmart.org/standards/technical-roadmap/. [Accedido: 2020]
[9] buildingSMART International, "Entity Component System (ECS) for IFC", buildingSMART Technical, [En línea]. Disponible en: https://technical.buildingsmart.org/projects/ecs-for-ifc/. [Accedido: 2023]
[10] Pixar Animation Studios, "USD Technical Introduction", OpenUSD, [En línea]. Disponible en: https://openusd.org/release/intro.html. [Accedido: 2024]
[11] Pixar Animation Studios, "Universal Scene Description Documentation", OpenUSD, [En línea]. Disponible en: https://openusd.org/release/index.html. [Accedido: 2024]
[12] buildingSMART International, "IFC5 Documentation", buildingSMART Technical, [En línea]. Disponible en: https://ifc5.technical.buildingsmart.org/. [Accedido: 2024]
[13] buildingSMART International, "IFC5-development", GitHub Repository, [En línea]. Disponible en: https://github.com/buildingSMART/IFC5-development. [Accedido: 2024]
[14] buildingSMART International, "IFC Overview", buildingSMART Technical, [En línea]. Disponible en: https://technical.buildingsmart.org/standards/ifc/. [Accedido: 2023]
[15] buildingSMART International, "Industry Foundation Classes (IFC) - Implementers Forum", buildingSMART, [En línea]. Disponible en: https://www.buildingsmart.org/resources/ifc-if/. [Accedido: 2024]
[16] buildingSMART International, "IFC Schema Specifications", buildingSMART Technical, [En línea]. Disponible en: https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/. [Accedido: 2024]
[17] buildingSMART International, "mvdXML Documentation", buildingSMART Technical, [En línea]. Disponible en: https://technical.buildingsmart.org/standards/mvd/mvdxml/. [Accedido: 2024]
[18] buildingSMART International, "What We Do", buildingSMART, [En línea]. Disponible en: https://www.buildingSMART.org/about/what-we-do/. [Accedido: 2022]
[19] International Organization for Standardization, "ISO 19650-1:2018 Organization and digitization of information about buildings and civil engineering works", ISO, [En línea]. Disponible en: https://www.iso.org/standard/68078.html. [Accedido: 2018]
Escribir comentario