Trabajo colaborativo

Archivos IFC como base de la colaboración

Publicado por

Un principio fundamental de la metodología BIM es la colaboración (ver una definición de BIM) y para esto los archivos IFC son una pieza clave. De hecho los archivos IFC son la base fundamental de la colaboración. De una forma muy simplificada, sirven para compartir datos entre herramientas.

Pero, ¿qué son los archivos IFC?. Vamos a ver qué son y para qué sirven.

La colaboración

La metodología BIM busca hacer una gestión adecuada de los datos y poder compartirlos ágil y fiable entre:

  • fases del ciclo de vida de los activos
  • entidades / empresas
  • disciplinas / especialidades
  • aplicaciones / software

Si se hace correctamente, se pueden reutilizar los datos muchas veces con grandes ahorros en tiempo y errores.

Una forma muy sencilla de compartir datos es utilizar todos el mismo sistema y de hecho la misma herramienta y en la misma versión. Algo parecido a un archivo tipo DOC, que es prácticamente universal.

Pero en otros ámbitos fuera del procesado de textos esto es imposible porque:

  • hay diferentes tipos de herramientas para cada tipo de problema
  • hay muchos suministradores de software
  • continuamente se actualizan las versiones de cada herramienta

Como cada herramienta organiza los datos de una manera específicamente diseñada para los problemas que resuelve y según la empresa que la genera, resulta que lo más probable es que no haya dos que coincidan completamente. Así que ¿cómo hacemos para compartir los datos entre ellas?

Una alternativa sería hacer “traductores” o “conectores” de cada herramienta con las demás, pero obviamente esto no es nada práctico.

La propuesta IFC

Lo que se plantea con IFC es una forma estándar de organizar los datos y las relaciones entre ellos (un modelo de datos). Así todos los actores serán capaces de generar e interpretar estos modelos. Es en definitiva un “idioma” común que todos pueden utilizar para entenderse.

Esta forma de organizar los datos se recoge en una especificación, el esquema IFC, que es:

  • abierto: es de dominio público
  • neutral: no depende de ningún suministrador de software

Esto implica que:

  • quien quiera puede aprender a trabajar con este tipo de modelos de datos
  • cualquier empresa puede desarrollar software que trabaje con ellos y no hay conflictos por tanto de copyrights, secretos industriales, monopolios, etc.

Obviamente, quien no sea capaz de trabajar con estos modelos tendrá más dificultades y resistencias que los demás actores para interactuar con ellos.

IFC es un esquema, una especificación, de cómo organizar datos y las relaciones entre ellos

Cómo se estructuran los datos en los modelos IFC

La “C” de IFC corresponde a clases en el concepto informático de la programación orientada a objetos, donde una clase es una especificación de cómo se genera un objeto.

Una clase podría ser “ventilador”, y todos los objetos que generemos (instanciemos) a partir de esa clase serán “ventiladores” u “objetos de la clase ventilador”. Como todos son ventiladores, todos tendrán las propiedades de un ventilador y harán las cosas que hacen los ventiladores. Propiedades para un ventilador pueden ser la potencia, velocidad de rotación, fabricante, modelo, color, precio, fecha de compra, de montaje,….

Con la clase “ventilador” generamos ventiladores. Todos tienen propiedades y comportamientos de un ventilador

Podemos tener por ejemplo otra clase de “interruptor”, con la que generamos interruptores, todos con las propiedades y comportamientos de un interruptor. Propiedades típicas podrían ser circuito, fabricante, modelo, color, ubicación o intensidad máxima.

Con la clase “interruptor” generamos todos los interruptores.

Teniendo interruptores y ventiladores, para cada ventilador es interesante saber qué interruptor lo acciona. Y viceversa, para cada interruptor interesa saber qué acciona. Estas relaciones también se recogen en los modelos IFC.

Relaciones entre clases: en este caso cada ventilador tiene un único accionador. Pero hay interruptores que activan varios ventiladores.

Por otra parte, hemos dicho que las clases “ventilador” e “interruptor” tienen una propiedad llamada fabricante. Podemos crear una clase “fabricante” con la que generaremos los fabricantes que necesitemos con propiedades como nombre de empresa, dirección, persona de contacto, … Y definiremos relaciones entre los objetos de la clase fabricante con los objetos de tipo ventilador, interruptor, etc.

Con la clase “fabricante” generamos todos los fabricantes.

Así que hay clases para todo, desde activos físicos como puertas, columnas o equipos de todo tipo a sistemas, actores o tareas. Y los objetos pueden tener todas las propiedades y relaciones que hagan falta durante el ciclo de vida completa de los activos.

El entregable IFC

Ahora que sabemos cómo tiene que ser la organización de los datos para que los colaboradores la puedan entender, queda ver cómo generamos ese modelo y cómo lo entregamos.

Filtrado de datos

Lo primero a tener en cuenta que cuando compartimos datos es que lo hacemos para que alguien los utilice para un fin determinado. Y lo ideal, por supuesto, es compartir los datos necesarios y únicamente esos datos. Ninguno más.

Filtrado por tipo de dato

Supongamos por ejemplo que diseñamos estructuras, y por tanto del modelo de las instalaciones únicamente nos interesa el volumen exterior de los elementos que las componen. O imaginemos que únicamente queremos obtener la información necesaria para la operación y mantenimiento y no resulta relevante el resto.

Según el uso que vayamos a hacer del archivo IFC el contenido deberá será uno u otro, y para eso se utilizan los Model View Definition (MVD).

Los MVD describen qué objetos, representaciones, relaciones, conceptos y atributos tiene que contener el archivo IFC para que sirva al receptor y su software para completar una tarea determinada. Y por supuesto pueden contener muy pocos datos o todos los de nuestro modelo.

Por ejemplo para un muro, podemos tener un MVD que contenga la geometría completa y otro que contenga únicamente qué espacios limita y su resistencia al fuego.

Algunos ejemplos de MVD serían:

  • Architectural Design to Structural Design
  • Architectural Design to Quantity Takeoff
  • Building Envelope Design to Energy Analysis
  • Construction Operations Building Information Exchange (COBie)

Los MVD se codifican en archivos mvdXML, y los modelos se suelen chequear de manera automatizada con el MVD para comprobar si cumplen con los requisitos que se especificaron previamente.

Filtrado por objeto

Siguiendo con el ejemplo del muro, supongamos que tenemos dos contratistas y que cada uno va a ejecutar una parte. Necesitamos en este caso proporcionar un archivo a cada contratista con su parte del muro. Lo que podemos hacer es utilizar el mismo MVD y dos exportaciones filtrando en cada una únicamente la parte necesaria.

Generación de archivos IFC

Una vez definidos los datos que vamos a compartir, nuestro software “convierte” el modelo de datos interno, con sus clases, objetos, propiedades, …, al esquema IFC, y el resultado de esa conversión será lo que entregaremos a nuestros colaboradores. Estos son los denominados archivos IFC.

Hay tres formatos fundamentales de archivo IFC generados según la ISO-10303:

  • .ifc: es un archivo de texto de tipo STEP-File
  • .ifcXML: es un archivo XML de tipo STEP-XML
  • .ifczip: es un archivo comprimido ZIP que contiene uno de los anteriores

En cuanto a contenido, los tres formatos llevan exactamente los mismos datos organizados de la misma manera, y el más habitual es el .ifc.

Hay otro formato que es de tipo excel y que se utiliza para operación y mantenimiento. Es el MVD COBie (Construction to Operation Building Information Exchange).

Versiones de IFC

Desde 1996 se han realizado diferentes versiones de la especificación y se está trabajando permanentemente en mejoras (ver https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/).

Actualmente la versión más moderna es la 4, pero se está trabajando ya en la 5, que incorporará más elementos propios de las infraestructuras.

También se está trabajando en facilitar el paso a trabajo en web con el uso de OWL – ifcOWL (Ontology Web Language).

Consideraciones

  • Los objetos se exportan con un identificador que los hace únicos, lo que permite hacer seguimiento de los mismos en sucesivas revisiones de la exportación.
  • La exportación de modelos a IFC implica una conversión de las clases internas a las clases IFC, lo que suele requerir un mapeo
  • En el otro extremo, la importación de modelos implica una conversión de clases IFC a clases internas de nuestro software, lo que suele requerir otro mapeo
  • Si utilizamos en nuestra herramienta clases que no existen en IFC, no podremos exportar o importar los objetos de esa clase, o tendremos que utilizar alguna equivalencia que tendrán que conocer quienes generen y utilicen los modelos exportados.
  • Configurar la exportación a IFC para que contenga todo lo que tiene que contener, y nada más, es un trabajo nada fácil y que consume tiempo y recursos. Por eso hay que planificarlo, y dotarlo, y es recomendable hacerlo al principio del proyecto para evitar problemas durante el desarrollo del mismo.

Resumen

Los puntos importantes a recordar sobre los archivos IFC:

  • los archivos IFC son la base de la colaboración en BIM
  • se generan para un uso específico: el IFC que se utiliza para O&M no es el mismo que para coordinación geométrica ni para eficiencia energética.
  • contienen únicamente la parte que queramos de los datos de nuestro modelo
  • están estructurados de una forma que todas las herramientas IFC los “entienden”
  • son un entregable, y como tal requieren de una preparación adecuada

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.