IFC… el rey esta desnudo.

IFC… el rey esta desnudo.

Entre los recuerdos que aún mantengo de mi paso por la EGB (Educación Primaria para los lectores del otro lado del charco) hay uno, de uno de un libro de Lengua de 3º. En mi recuerdo veo una viñeta donde un pequeño niño apuntaba con su dedo al rey… «El rey esta desnudo».

IFC no acaba de funcionar… vamos quizá nunca empezó a funcionar. Tenemos que reconocer, sin tapujos, que en el sector de la construcción llevamos varias decenas de años de retraso frente a otras industrias. Cuando comencemos por reconocer nuestra situación comenzaremos a solucionar nuestros problemas. Es como cuando un alcohólico se planta frente al espejo y le dice al señor que tiene enfrente: «Amigo tenemos que cambiar».

El sector de la construcción (sector AEC) tiene que realizar su digitalización ya. No es posible retrasar más el paso que tenemos que dar hacia esa construcción más eficiente. La metodología BIM viene a suponer un primer framework para comenzar este proceso, necesario pero quizá no suficiente. Parte de este framework de trabajo recae sobre IFC. El formato para gobernarlos a todos.

Durante un tiempo de mi vida, estuve realizando trabajos de prototipado y fabricación digital. Desde ProEdge, Catia, Solidworks… se exportaba en ese formato mágico de «pasos» STEP, (Standard for the Exchange of Product model data) los resultados de esa comunicación entre distintos programas era bastante decente. STEP lleva en la industria desde mediados de los años 80… por esas fechas aparecía las primeras versiones de Archicad. Cuando el sector industrial se empezaba a estandarizar, STEP se basa en varias ISO, la construcción comenzaba a usar la tercera dimensión. Hasta mediados de los noventa no se empieza a hablar de las IFC… (las clases a que se refiere la C de IFC son clases de programación… programación orientada a objetos vamos). La buildingSmart comenzó su labor realizando una «transposición» de las herramientas más cercanas que encontró y cogió como base para sus IFC STEP. STEP esta basado en Express y su definición gráfica en Express-G… Hasta aquí todo correcto, verdad?

Pero estamos en el año 2016, si alguien ofreciera una cantidad de dinero desorbitante y pidiera crear un formato de colaboración en el sector, ¿alguien en su sano juicio utilizaría Express y Express-G? No hace falta que de la respuesta verdad?

¿No es el momento de refundar las Foundation Classes?

¿No es el momento de utilizar el formato XML como estándar? Formato de marcado extensible… qué me gusta la palabreja del final EXTENSIBLE, define tu namespace apropiado y ve añadiendo tus nuevas definiciones. Normalizado si, pero extensible. Cada vez que veo una especificación nueva de IFC aparece como logro… tropecientos mil nuevos entities… porque no un lenguaje extensible y que la buildingSmart se encargue de los namespace? De esta manera quizá no tendríamos que sacar una versión de IFC cada cuarto de hora.

Express-G en 2016… venga ya! Pero si hasta la propia OMG utiliza UML! hay que revisar el parte inferior derecha de los pc… justo debajo de la hora viene el año en el que estamos… Si alguien lee esto (algunos de los miles de suscriptores de la web supongo que habrá llegado hasta aqui) por favor vamos a utilizar UML ya.

Se que alguien me va a decir que existen un IFCxml y que se puede mapear-traducir la información de Express-G a UML. En el mapeado siempre se pierde algo… y Express-G siempre ha estado más orientado a ER que a OO…

Si la bases del framework en el que nos movemos están tan desfasadas ¿cómo queremos que funcione el invento? Luego vienen los llantos, que si mi programa «lee» bien, que si el tuyo «escribe» mal IFC. O los desarrolladores de software son todos muy malos (en ambos sentidos) o las reglas de juego no son univocas…

Si la simple lectura y escritura de un IFC, ya es compleja. Las MVD, vienen a complicar todo un poquito más. Las MVD, son esenciales en un formato de intercambio. ESENCIALES repito. Un IFC para el calculo de climatización no puede ser el mismo que el se use para definir la geometría del aplacado… No puede serlo.

Y mientras discutimos como pasarnos la información se nos escapa lo realmente importante. Intercambio de información… para qué?

«Es que le tengo que mandar al ingeniero los planos en IFC y no sabe como leerlos». Esto lo he oído ya muchas veces… seguimos siendo enanos montados en hombros de gigantes. 

Hay que revolucionar el sector, no evolucionarlo.

Mi proposición… una base de datos única. Un PLM: product lifecycle management. Una base única de información y definir un lenguaje de consulta adecuado. Se arreglo el problema… no hay fallos en el intercambio de información… no hay que intercambiarla. No hay que definir MVD solo hay que saber qué se consulta.

«El tío del Facility quiere que el mande un ifc con un nivel de información…» nada no sigas… que él acceda a la base y agregue o modifique la información significativa para su alcance. Aquí esta esta la revolución en el sector. Los BIM Managers del futuro lo único que deben saber es  qué se consulta, cómo y por quién…

Cuando hace ya muchos años Dassault presento la plataforma Enovia (Catia V6) muchos no entendieron el salto. Un software de «diseño» que no tiene un archivito con el modelo… «que tengo que instalar un servidor de bases de datos… »  pues claro! vamos a gestionar el ciclo completo de vida de un producto, ¿dónde? en un modelo 3D… no hombre, no. En un base de datos estructurada. Si hay que simular el modelo se simula y los datos se recogen en la base. Si hay que calcular, se calcula y los datos a la base de datos. Que el producto se rompe y hay que modificar el diseño… pues el erp se conecta con la base de datos… y se arregla el diseño.

Cuando dentro de unos años, muchos me temo, acabéis usando una base de datos centralizada para acompañar el PLM de un proyecto de edificación acordaros de este post…. ah! por cierto si aún no te has dado, cuenta el rey va desnudo. 

 

Tags:
, , ,
Jose Gemez Jimenez
josegemez@gmail.com

José Gémez, nacido en Córdoba en 1977, arquitecto experto en BIM y coordinador y formador del Área BIM de Animum Creativity Advanced School. Concretamente en el Máster - BIM Manager con Autodesk Revit (Título Propio de la Universidad San Pablo CEU). Actualmente doctorando en BIM en la Universidad de Málaga, con la tesis "Tecnología BIM aplicada a la construcción"

5 Comments
  • Jesús Valderrama
    Posted at 18:45h, 25 mayo Responder

    clap clap clap! Pedazo de artículo, sin tapujos. Tu propuesta… totalmente de acuerdo. Una base de datos central, lo que no está en la base de datos (o enlazada a ella) no está en el proyecto. A partir de ahí, que los softwares den la capacidad a los usuarios de extraer, insertar o modificar la información que de ellos dependa o a las que ellos afecte. El concepto de interoperabildad en la industria tiene que cambiar, interoperar tiene que ver con el intercambio de datos, confundir data con file es limitante y sólo da problemas.

  • Sergio Muñoz
    Posted at 08:38h, 26 mayo Responder

    Hola Jose,

    En primer lugar, felicitarte por tu articulo en el que describes perfectamente el quid de la cuestión que es la necesidad de poder consultar la información de forma adecuada.

    A partir de ahí, que es algo en lo que creo estamos todos de acuerdo, queda ver cuál es la mejor solución.

    Lo que también tengo claro, es que las soluciones deben ser acordes a los tiempos, sobre todo en materia tecnológica, pero eso no significa que la tecnología lo resuelva todo. Entiendo lo que dice Jesús de ficheros Vs Servidor Web, pero no nos engañemos, no me sirve de nada un Servidor Web si no nos hemos puesto de acuerdo en como clasificar la información en ese servidor y en como consultarla, por lo que la necesidad de estandarizar la generación de información sigue estando.

    Cuando nace IFC, después de muchas discusiones, se decide por tomar un camino. Años después, y viendo la necesidad de realizar consultas específicas aparece MVD, luego los data dictionaries, nuevas versiones de IFC, etc.
    Actualmente, echando la vista atrás podemos pensar que lo mejor era haber hecho otra cosa a día de hoy es lo que tenemos.

    A partir de aquí, como con un edificio «viejo», es cuando nos podemos plantear si lo rehabilitamos o si lo derribamos y hacemos uno nuevo teniendo en cuenta tanto las necesidades como las tecnologías actuales.

    Te invito a plantear una propuesta al respecto junto a otros miembros de BSSCH que poder trasladar a buildingSMART en los próximos Technical Summit, o en el de Korea de Septiembre o en el que se celebrará en España en la Primavera de 2017.

    Un saludo

  • Jesús Valderrama
    Posted at 11:43h, 26 mayo Responder

    Sergio, está claro que son necesarios los estándares, de eso nadie tiene duda. En cuanto a lo que comentas de rehabilitar o hacer de nuevo, es un tema complejo y estoy seguro que en la BS habrán estudiado en profundidad el alcance de las distintas opciones y su viabilidad. Primavera de 2017 es una gran oportunidad y una suerte de realizar el Technical Summit, no sé si Jose tendrá idea de darse una vueltecita por Korea! jejeje

  • Ivan Alarcon
    Posted at 07:10h, 29 mayo Responder

    Hola a todos.
    Gracias Jose por el artículo, que nos permite reflexionar sobre el tema.

    Como ya se vio el EUBIM 2016 la conexión de bases de datos con los modelos BIM parece una necesidad inmediata. En el fondo el archivo de Revit es una base de datos estructurada, con tablas y relaciones entre ellas, como se puede ver si se exporta a ODBC (supongo que ArchiCAD, AllPlan, etc, tambien lo serán).

    Yo quiero darle una oportunidad a IFC que junto con IFD, IDM, etc y el estandar ISO, tiene que ser capaz de definir, codificar y estructurar la informacion de los productos y sistemas constructivos. Por supuesto que necesita mejoras (por ejemplo al exportar el modelo estructural, o incluso incorporar UML a la definición de geometrías), pero empresas españolas (como Cype, Artek, etc) están consiguiendo buenos resultados basándose en IFC, a pesar de esas limitaciones.

    Creo que efectivamente los programas de modelado BIM no están tomándose en serio la interoperabilidad con IFC. Sus importadores/exportadores a IFC no tiene una guía estandarizada de mapeados a las clases de IFC y sus parámetros. Por no hablar de que por ejemplo Revit, ni siquiera lee IFC 4, ni ha establecido el control de cambios.

    Siento disentir con la frase de «IFC pierde informacion». Es mas un problema de los visores IFC, que del propio IFC. Hoy por hoy, para comprobar si he exportado «bien» un IFC lo tengo que pasar por varios visualizadores, ya que en cada uno de ellos me aparecen propiedades o visualizaciones que en otro no aparecen, por lo tanto la informacion esta en el IFC, y el problema es que determinado visualizador no muestra esa informacion, o puede ocurrir que no he realizado bien el mapeo de clases con las categorías al exportar.

    A ver si conseguimos que la interoperabilidad entre agentes y programas sea una realidad

    De paso, ya que estamos, ¿Cuando conseguiremos que las bases de precios españolas se adapten a una estructura de capítulos y partidas basadas en estándares (tipo Omniclass, Uniformat, masterformat, IFD, ISO 12006-2:2015(en), o un nuevo estándar Europeo). De las más de 15 bases de datos de precios (curioso que se denominen bases de precios) no he encontrado dos con la misma estructura de capítulos y partidas. Creo que necesitamos una codificación clara de los productos y sistemas constructivos, para que los fabricantes puedan generar su bases de datos, acorde a esa codificación, con la informacion estructurada (y no en un PDF) para que podamos relacionarla en nuestros programas

  • Borja S.Ortega
    Posted at 15:34h, 21 noviembre Responder

    Felicidades José. Muy interesante. Un saludo

Post A Comment

A %d blogueros les gusta esto: