¿Por qué es necesario poder editar IFC's?

Con independencia de quién debe o no debe editar un IFC, hace tiempo que vengo insistiendo en la posibilidad de poder editar (léase como capacidad de manipular, agregar información, eliminar información, organizar la información ya existente… etc.) los archivos exportados a formato IFC.

No voy a entrar en el debate sobre si se debe o no se debe editar el IFC ni en quién o quiénes tendrían que hacerlo en caso que sí. Son cuestiones que a futuro podría resolver la legislación o en su defecto, una matriz de responsabilidades incluida en el Plan de Ejecución BIM de cada Proyecto.

En este artículo me voy a centrar en justificar la necesidad de poder hacerlo y además, demostrar que efectivamente es posible con mayor o menor esfuerzo y éxito en mayor o menor grado según la solución escogida. 

Evitar ediciones de IFC de forma malintencionada podrá ser resuelto por mecanismos como:

• Sistemas de archivado y repositorio de las versiones aprobadas.
• Visados de archivos formato IFC.
• Sellado-Capado vía contraseña (como archivos PDF con contraseña de seguridad que evitan ser abiertos o evitan que se copie/manipule).
• Firmado digital del archivo IFC (similar a la firma y o certificados en archivos pdf).
• Blockchain.
• Trazabilidad incrustando información sobre quién editó qué y cuándo lo hizo sobre las entidades IFC o sobre el propio archivo IFC completo.
• Otras soluciones.

1. Modeladores con softwares que no permiten la agregación de parámetros. 

En un supuesto de cliente demandando Property Set’s propios (por ejemplo, PROMOTOR X que quiere que a nivel IfcProject se añada un Property Set llamado “Promotor X Properties” con un parámetro Código de Proyecto de tipo numérico y con valor “150236,” un parámetro llamado “Nombre de Proyecto” con valor de texto “Ampliación zona B Aeropuerto Z” y otro parámetro de tipo lista desplegable en la que se haya seleccionado para esa fase el valor “fase Proyecto de Ejecución”, por otro lado, requerimientos razonables para documentar un proyecto), ¿puede mi software de modelado actual cumplir con dicho requerimiento? A día de hoy (septiembre 2018) probablemente no.

2. Planificador de obra sin software de modelado.

Pensemos ahora en un especialista en Planificación de Obra al que le pedimos algo que antes no hacía (enlazar informáticamente elementos de los planos a un diagrama Gantt). Ahora tiene que asociar elementos 3D de modelos BIM a dicha estructura de planificación. ¿Tendría dicho planificador que aprender software de modelado? ¿Cuántos y cuáles de ellos si pensamos en una constructora a la que le pueden llegar modelos de nativos de cualquier software de modelado? ¿No sería más razonable que mediante un visor/editor IFC sencillo organizara el modelo BIM y lo codificara según la Estructura de Planificación para asegurarse de que manera automática tras cada actualización del modelo general, cada elemento 3D esté relacionado con la/las actividades de obra que le corresponden? 

3. Gestor de mantenimiento y/o promotor que requiere actualizar datos según la fase operación.

Misma pregunta que antes, pero con otro agente: un gestor de mantenimiento o un promotor que necesita actualizar el nombre de una luminaria porque esa que vino en el modelo As built acaba de ser sustituida por otra marca de similares características geométricas o necesita añadir la fecha de revisión que ha tenido lugar esta semana en relación a cuestiones técnicas de un ascensor.

Soy partidaria que, en fase de mantenimiento, dado que el activo puede sufrir cambios “geométricos” (por ejemplo, una ampliación a tercer carril en infraestructura de carreteras o en el caso de edificación, una remodelación en la distribución original de la planta tercera en un edificio) que el modelo pueda ser editado geométricamente. Lo que no soy partidaria es del “secuestro” por parte de una herramienta escogida hace 10-20-40-80 años para modelar el proyecto y la necesidad de actualizar dichas reformas sobre el nativo basado en aquella. Y aquí es cuando surge la idea de la necesidad de un formato de intercambio real, completo y suficiente. Este formato podrá ser a futuro un formato nativo adoptado por la industria o un formato no dependiente de desarrolladores de software con intereses comerciales, sino de una organización independiente y cuyo negocio no se fundamente en vender más licencias.

Existen algunos mitos relativos al IFC que me gustaría cuestionar como los siguientes:

1. El IFC no se puede editar.

Esto es absolutamente falso. Una cosa es que se pueda y otra que se deba. Poderse (poder, en su acepción de tener capacidad o potencialidad para hacer algo), se puede. Y no sólo lo digo yo, sino que también lo dice uno de los expertos en IFC de AEC3 como Thomas Liebich en el pasado curso impartido desde buildingSMART Spanish Chapter en Madrid el pasado mes de Abril 2018.

Además puede demostrarlo cualquiera que abra el archivo en formato IFC con el Bloc de notas, modifique datos editando el texto y guarde de nuevo sobre-escribiendo el IFC como en el ejemplo que sigue:

Basta hacer una copia del archivo IFC original, renombrarlo, abrirlo con el Bloc de Notas, buscar los parámetros, editar sus valores y guardar los cambios.

Tras hacerlo, podemos volver a visualizar el archivo IFC y vemos los cambios introducidos.

Con esta prueba queda demostrado que se puede y de una forma relativamente sencilla, ya que apenas lleva 2 minutos. ¿Es éticamente correcto? Obviamente en este caso extremo donde se cambian nombres de personas, software, versiones, fechas… la respuesta claramente es NO. Pero actualmente el sector está expuesto al riesgo de estas ediciones falseando datos de la misma manera que estamos más expuestos a que nos roben si dejamos la puerta de nuestra casa abierta. Si no confiamos en la bondad las personas para evitar intrusiones, tampoco creo sea conveniente confiar en la “no edición del IFC por cuestiones éticas”.

2. Si añades parámetro customizados ya no cumples el estándar IFC. 

Tampoco es correcto. Según el mismo experto mencionado antes, el IFC está preparado como estándar internacional pero naturalmente buildingSMART no puede bajar al detalle de pormenorizar a nivel país X, promotor Y, proyecto Z, fase J, ingeniería P, constructora R… etc.

Adaptar el entregable en formato .ifc a estándares nacionales, estándares de proyecto, estándares de fase… estándares de agentes (promotor, ingeniería, constructora, gestor de mantenimiento… etc.) requiere pensarlo, documentarlo en los requerimientos e implementarlo en cada fase para cada proyecto.

Por tanto, si añadimos Property Set’s (agrupaciones lógicas de parámetros o conjuntos de los mismos), Properties (parámetros de tipo texto, tipo número, tipo verdadero-falso, tipo lista… etc), y Values (el dato asociado al parámetro para dicha entidad de la que está colgando), no significa que nos estemos saliendo del estándar IFC aunque sí puede estar implicando salirse de estándares tipo MVD (Model View Definition) como Coordination View para IFC 2x3 o Design Transfer View para IFC4. Esto implica que sí podemos pensar en MVD’s customizados y no por ello estar entregando modelos BIM que no cumplan con el estándar IFC.

Mirando ahora hacia las distintas soluciones de modelado y/o modelado + cálculo del mercado y tras el análisis de varias de estos modeladores llevado a cabo de manera interna en INECO nos encontramos con lo siguiente:

• Algunas soluciones, la mayoría, no permiten añadir parámetros a niveles “abstractos” del IFC como IfcProject, ifcSite, IfcBuilding o IfcBuildingStorey.
• Algunas soluciones de cálculo y modelado (ya sea de instalaciones o de estructura) no permiten la agregación de parámetros ni grupos de parámetros ni siquiera a nivel entidad geométrica “tangible” (pilares, forjados, tuberías…).
• En su mayoría tampoco permiten la agregación de clasificaciones que viajen en el parámetro preparado para ello del IFC (IfcClassificationReference).
• En su mayoría tampoco permiten la organización del IFC según estructuras no jerárquicas como por ejemplo, organización por capas o generar agrupaciones de elementos tipo IfcElementAssembly, IfcZone, IfcGroup o IfcSystem.

A día de hoy yo aún no he encontrado una solución de modelado que cumpla con TODOS estos requisitos. Y en el caso de haberla encontrado la siguiente pregunta sería ¿sirve para Infraestructuras o sólo para Arquitectura? ¿es lo suficientemente eficiente para cálculo Estructural o Instalaciones o sólo la puedo contemplar como herramienta de modelado geométrico con información no gráfica asociada?

Según el apartado anterior ya podemos intuir el problema: requerimientos demandados que hay que cumplir con herramientas ya adquiridas que en la mayor parte de los casos pueden no ser capaces… Y este es el momento donde planteo tres posibles soluciones a corto plazo:

• Editar el ifc en formato de texto con el bloc de notas

Esta “solución” en mi opinión es inviable ya que quienes al final incorporan información son ingenieros, arquitectos, gestores de mantenimiento, promotores… en ningún caso informáticos y por tanto sin conocimientos de lenguaje de escritura IFC.

• Importar el ifc en un software que no tenga dicha limitación y editarlo

Esta alternativa es viable, aunque teniendo en cuenta que no encontré ninguno que pudiera con toda la casuística planteada anteriormente, nos estaría obligando a contar con varias plataformas de modelado. Es más, podría llevarnos a pensar para qué utilizar una herramienta que no me permite incorporar esa información a nivel de al menos, elemento cuando hay otras que sí me modelan y me lo permiten.

• Editar el ifc en un software específico de edición de IFC’s

Afortunadamente estos softwares ya empiezan a existir en el mercado, aunque a día de hoy con muchas limitaciones.

Vista la necesidad de editar y enriquecer el modelo en su formato IFC, se antoja necesario que puedan mejorar las prestaciones en este sentido tanto de los softwares de modelado como de las incipientes aplicaciones que trabajan con IFC’s de forma específica.

Lo que personalmente le pediría a un software de edición de IFC’s sería lo siguiente:

• Modificar/Añadir Clasificaciones de entidades geométricas en el parámetro IfcClassificationReference.
• Visualizar el IFC según la estructura de clasificaciones.
• Consultar el IFC según parámetros y/o clasificaciones.
• Extracción de tablas Excel según dichas consultas.
• Modificar/Añadir Pset’s.
• Modificar/Añadir Properties (según data types: IfcText, IfcInteger, IfcBoolean, etc.).
• Modificar/Añadir Property Values.
• Federar varios Ifc’s y crear uno único.
• Cambiar de un tipo de entidad geométrica a otra (pj. IfcColumn > IfcPile).
• Crear grupos de entidades geométricas (IfcSystem, IfcGroup, IfcZone e IfcElementAssembly) a los que también se les pueda agregar Pset’s.

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 por lo que a pesar del panorama algo desolador en este momento (septiembre 2018), no es descabellado pensar que en los próximos años podamos entregar modelos BIM en formato IFC completos, bien organizados, auditados y fácilmente consultables y/o editables.