IFC… el rey esta desnudo.

25 May 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.