Interoperabilidad 4D y 5D... ¿cueces o enriqueces?

Tirando del hilo... ¿es necesario editar IFC's?

Definido el título de esta píldora, podríamos iniciar su contenido de muy diversas formas. Una, muy interesante, sería abriendo un debate acerca de lo que debe ser entendido como interoperabilidad. Reservaremos, no obstante, esta cuestión para un desarrollo posterior.

 

Comenzaremos, ya en este segundo párrafo, tirando del hilo de una interesantísima píldora reciente, la que firma Pilar Jiménez Abós y en la que aboga por la necesidad de edición de los archivos IFC. Personalmente, no puedo estar más de acuerdo con ella, y como amante de la tecnología blockchain, creo que existen mecanismos para garantizar la alteración malintencionada de este tipo de documentos. Si Pilar se refiere, como primera causa necesaria de edición, a la limitación de ciertos modeladores para agregar parámetros al modelo, como segunda, aparece la conveniencia de gestionar la planificación de la ejecución de la obra, directamente sobre el modelo federado.

Consistencia y capacidad de los modelos

Qué duda cabe que el deseo de cualquier agente que se incorpora a un flujo colaborativo es heredar un modelo de trabajo lo más funcional posible -con información coherente, completa, etc., de tal forma que la riqueza -útil- de la información contenida en el modelo pueda simplificar y facilitar tareas posteriores. Si, puestos a revisar interferencias, desearíamos que nuestros modelos de partida fueran lo más consistentes posibles, puestos a llevar a cabo la planificación de la obra (o supervisar e incluso editar la ya realizada), querríamos igualmente que nuestros modelos dispusieran de cantidad, y por supuesto, de calidad, en lo que se refiere a la información 4D.

 

Salvo excepciones, el proceso de elaboración de un proyecto comenzará con la fase de modelado. Si, una de las razones aludidas por Pilar para la necesidad de edición de IFC’s deriva de la limitación de los modeladores a la hora de colocar cierto tipo de información en el modelo, deberemos intentar “exprimir” los modeladores para que esas limitaciones sean las menos posibles. Y, si exploramos los límites de estos modeladores, deberemos tener en cuenta los plugins, cuya función será, precisamente, expandir esos límites. 

Un plugin con mucho potencial: Cost-it

Hablaré aquí, necesariamente y por experiencia propia, de uno que funciona muy bien y que tiene por nombre “Cost-It”, cuya función principal será extraer del modelo toda aquella información que pueda resultar útil para obtener su presupuesto; este complemento de Presto para Revit, además, conectará ambas aplicaciones bidireccionalmente, de tal forma que esta relación funciona, tal y como dice Fernando Valderrama, consultor estratégico de Rib Spain y principal autor de Presto, como una “pareja de hecho”.

 

No es este lugar para entrar en pormenores de aplicaciones propietarias, pocos dudarán que Revit y Presto son el modelador BIM y el programa integrado de gestión del coste y del tiempo de mayor implantación en nuestro país.  La primera consecuencia de esa comunicación bidireccional, en aras de alcanzar los deseados niveles de interoperabilidad, será que el modelo IFC a generar desde un modelador BIM como Revit, se podrá ver enriquecido con toda la información 3D y 4D introducida en el archivo de Presto.

 

Y sí, programas como Revit, permiten la creación de fases y la asignación de los elementos del modelo, o sus partes, a cada una de las fases creadas, pero…, en un flujo de trabajo pretendidamente eficiente, siempre será mejor reservar cada tarea a aplicaciones especialistas. Establecida la vinculación entre un archivo de Revit y uno de Presto, resultará indudablemente más eficaz crear una planificación técnica o temporal, y realizar el control de la ejecución, en programas como Presto, para luego, gracias a la comunicación bidireccional entre ambos, incorporar, si así lo deseamos, toda esa valiosa información en el modelo de Revit. Teniendo en cuenta que, gracias a plugins como Cost-It, Presto puede hacer suyos todos y cada uno de los parámetros y sus valores del archivo de Revit, se antojan pocos límites…

El IFC de Revit, ¿cocido o enriquecido?

Pero aquí hemos venido a hablar de IFC’s. El modelo de Revit, enriquecido gracias a la información definida en Presto, podrá ser exportado a IFC y ese IFC, por supuesto, podrá contener como hemos dicho, la información 4D y 5D procedente de Presto. Esta posibilidad abre un abanico de posibilidades… ¿Podríamos, acaso, obtener la medición o el diagrama de Gantt del archivo IFC…? Pues sí, teóricamente sería posible; pero claro, lo teóricamente posible no es necesariamente práctico. De la misma forma que no utilizamos un IFC para obtener planos, tampoco parecería lógico utilizar un IFC para obtener una medición o una impresión del cronograma. Los tiros irían, más bien, por donde apuntaba Pilar en su píldora. Pensemos en un caso concreto; si federamos modelos en un visor IFC podremos, también federar modelos planificados y confrontar, también, su planificación. Por otro lado, el IFC obtenido a partir del modelo BIM “enriquecido” desde Presto nos permitirá realizar todo tipo de consultas: precios unitarios, referencia de catálogo, descripción referida a una base de precios de la construcción, pertenencia a fases, fechas planificadas de las actividades referidas a elementos del modelo, duraciones, etc., etc. Lo importante, en definitiva, será poder disponer de información valiosa en nuestro modelo de trabajo, información 3D, 4D y 5D que provendrá, tanto de los modeladores como de otras aplicaciones específicas que resuelvan otras fases del proceso. La incorporación a un flujo de trabajo OpenBIM exigirá la incorporación de toda esta información.

BIMcollabZOOM – Datos de identidad: Fase, costo unitario, descripción, clasificación (Base de Precios Junta de Extremadura).
BIMcollabZOOM – Datos de identidad: Fase, costo unitario, descripción, clasificación (Base de Precios Junta de Extremadura).

Centrémonos en el modelo IFC, o en el modelo federado obtenido a partir de varios modelos parciales; cualquier visor IFC nos permitirá no sólo visualizar las propiedades de ciertos elementos sino filtrarlos en una vista para, por ejemplo, comprobar cuáles de ellos quedan contenidos en una determinada fase. Con un mínimo control de filtros de vista podremos disponer de información gráfica asociada a las fases de planificación, fases de certificación, planificación o certificación a origen, codificación por color de la pertenencia de los elementos a una fase determinada, etc. Este procedimiento de trabajo aporta una dimensión visual muy tangible a la información no gráfica incluida en el modelo; esta es, en cierto modo, la esencia de la metodología BIM. La integración de varios modelos, correctamente codificados y planificados, permitirá la confrontación 4D de la escena global. Mostramos a continuación un ejemplo de visualización con filtros, la captura corresponde al visor gratuito de BIMcollab (BIMcollabZOOM).

BIMcollabZOOM – Vistas inteligentes: Visualización de una fase de planificación (resto de modelo atenuado).
BIMcollabZOOM – Vistas inteligentes: Visualización de una fase de planificación (resto de modelo atenuado).

Retomando el hilo. Edición del IFC.

¿Podríamos ir más allá…? Por supuesto; siempre se puede ir más allá. Volvamos a la situación planteada por Pilar, la de un Planificador de obra sin software de modelado. Detectadas incoherencias en el modelo IFC, o en el modelo federado a partir de los modelos parciales, ¿podrían simularse nuevas planificaciones y resolverse las incoherencias detectadas sin necesidad de recurrir a las aplicaciones nativas de modelado y “molestar” a los agentes intervinientes en fases anteriores del proyecto? Por supuesto que sí. ¿Cómo…? Editando el IFC. ¿Se puede…? Sí, se puede. Y no sólo de una forma tan espartana y críptica como la edición del archivo IFC mediante un simple Bloc de notas sino fácilmente, mediante el uso de software gratuito como el propuesto por ACCA software; nos estamos refiriendo a su visor IFC, también gratuito, usBIM.viewer+. Mediante el uso de esta aplicación no sólo resulta posible editar IFC’s sino que, además, resulta sencillo y seguro. Este potencial puede ser puesto a disposición de la planificación del modelo y, difícilmente podría encontrarse mejor ejemplo que el propuesto por Pilar.

usBIM.viewer+ – Ejemplo de modificación de propiedades de objetos del modelo
usBIM.viewer+ – Ejemplo de modificación de propiedades de objetos del modelo

Los contornos difusos del término "interoperabilidad"

Lo dicho hasta ahora pretende poner de manifiesto cómo, casi cualquier punto de partida, puede resultar válido para su integración en un flujo de trabajo abierto y colaborativo. Nuestro caso concreto parte del modelo de Revit enriquecido con la información de Presto. Cost-It establece una comunicación bidireccional y biunívoca (elemento de modelo de Revit = línea de medición de Presto) que, si bien y en principio, pudiera no entenderse como interoperabilidad en su sentido más purista (en tanto en cuanto que se limita a la relación entre dos formatos de archivos propietarios) acaba desembocando en el caudal OpenBIM, si este es nuestro propósito.

En la “distancia corta”, Cost-It exprime el potencial del archivo nativo de Revit hasta tal punto que hace de él un visor de la información no gráfica contenida en Presto. Gracias a este plugin, Presto consigue lanzar simulaciones que, en tiempo real, muestran sobre la ventana gráfica de Revit procesos constructivos basados en la planificación, estados de certificación, etc. Más allá de esto, y gracias a la comunicación bidireccional, Cost-It puede escribir en el modelo toda la información que, lejos de resultar útil en el modelo de Revit como tal, puede convertirse en una valiosa documentación del archivo IFC a utilizar en fases posteriores. Pongamos un ejemplo. Una línea de medición asociada a una actividad determinada puede quedar asignada a una fase de obra, de tal forma que, al estar dicha línea vinculada con un elemento del modelo gracias a un identificador único y común en ambas aplicaciones, cada ejemplar podrá recibir los datos que sean de interés. Revit podrá procesar esa información (p.e., fase de creación) y utilizarla en procesos propios (tablas de planificación, filtros de vista, etc.). Otros datos más específicos (p.e., fechas concretas de inicio y fin planificado para esa misma actividad) podrían no resultar tan útiles en el modelo de Revit y, sin embargo, ser de tremendo interés para su consulta en obra, segura e inmediata, directamente sobre el archivo IFC. 

Conclusiones

Programas específicos como Presto proporcionan el entorno propicio para generar información 4D y 5D; aplicaciones como Cost-It permiten el trasvase de datos a modelos propietarios y, finalmente, los modeladores permiten generar el equivalente estandarizado con la información correctamente mapeada.

 

En este momento, podría hacer mía la conclusión de Pilar; el mercado de software BIM avanza muy rápido y cada vez son más los desarrolladores que comprenden la necesidad de una correcta gestión de IFC (…). Afortunadamente, y aunque queda mucho camino por recorrer, el camino ya andado permite emprender ciertos procesos con garantías de éxito. 

Autor

Marco Pizarro  es Arquitecto, con experiencia en muchos campos (alumno y profesor universitario, técnico municipal, de visado, de centros de asesoramiento colegiales, calculista, diseñador...) y, desde hace unos años, usuario, consultor, formador, beta tester y apasionado de la metodología BIM.

 

Escribir comentario

Comentarios: 2
  • #1

    Pilar Jiménez (jueves, 16 mayo 2019 10:43)

    Marcos, muchas gracias por las menciones en tu artículo.

    Creo que el asunto de editar ifc's seguirá generando controversia durante algún tiempo...

    Me permito plantearte dos cuestiones que generan debate internamente en la subdirección BIM de ineco a raíz de tu artículo:

    1. No entendemos bien cómo obtener un IFC enriquecido con datos de coste y plazos desde presto/cost-it...

    2. En Ineco trabajamos con muchos software de modelado (aecosim, revit, istram, allplan, tekla... Etc) combinados dentro de un mismo proyecto. Cuál sería tu flujo de trabajo en esta situación?

    Un saludo

    Pilar Jiménez

  • #2

    Marco A. Pizarro (jueves, 16 mayo 2019 17:55)

    Hola Pilar.

    El archivo IFC muestra un potencial que excede su propia vocación, de ahí la inevitable controversia; la posibilidad de edición sencilla abre una ventana donde muchos pensábamos que no había más que un muro. Tú has puesto voz a esa posibilidad, así que es justo referenciarte.

    Te respondo comenzando por la segunda cuestión (la fácil); afortunada o desafortunadamente, hasta ahora no he debido enfrentarme a flujos de trabajo en los que converjan tantos modeladores combinados dentro de un mismo proyecto. Mi breve píldora se refiere únicamente a un flujo de trabajo basado en Revit y Presto. Esto nos llevaría a responder a la primera pregunta, Cost-It es una aplicación muy específica que permite transferir datos de uno a otro programa; la información 4D y 5D incorporada en al archivo de Presto, puede ser volcada al modelo de Revit y, de ahí, exportada al modelo IFC.

    De forma análoga, cada modelador dispondrá de sus propios procedimientos para incorporar esa información 4D/5D como paso previo a la exportación a IFC. Como usuario de Allplan, me consta que, por ejemplo y en este caso, podríamos hacerlo, también desde Presto, vía Excel. Desconozco procedimientos equivalentes para Tekla, Istram, OpenBuildings, etc... La cuestión es que con el empleo de Cost-It es tan sencillo e inmediato que..., si no existen aplicaciones similares, deberían inventarse.

    Convenientemente codificada esa información en el modelo federado IFC, podremos operar con ella independientemente de la procedencia de cada modelo. A partir de ahí, la posibilidad de editar esos campos de información, abre la ventana a la que antes me refería; una ventana tan controvertida como potente.

    Un saludo.