En algunos foros técnicos se escuchan a veces ciertas afirmaciones relativas a la limitación de las clases IFC en cuanto a su capacidad para poder clasificar el modelo BIM de forma suficientemente profunda. A ello se suman también ciertas limitaciones de algunas plataformas de modelado BIM en la gestión del IFC Schema. Si bien es cierto que determinadas disciplinas, como las instalaciones, exigen en muchas ocasiones una granularidad elevada en cuanto a su clasificación, la realidad de dichas afirmaciones no acaba siendo cierta.
En ese sentido, el objetivo de esta píldora es doble y se resume en:
- Mostrar la profundidad en niveles de clasificación de elementos del propio IFC Schema.
- Exponer como ArchiCAD automatiza el proceso de mapeado de un sistema de clasificación BIM a los Tipos Predefinidos de IFC (Predefined Types).
1. Niveles de Clasificación en IFC
En primer lugar y como punto de partida conviene tener claros los conceptos fundamentales del IFC Schema. Se trata de una tecnologia orientada a objetos y su estructura está basada en las denominadas “clases” (también llamadas Entities o Entidades).
Los distintos tipos de clases existentes en el esquema se organizan de forma jerárquica, conteniendo cada una de ellas parámetros relativos a su identificación, comportamiento y distintos tipos de datos.
Un determinado subtipo de clase serán los elementos/componentes físicos del modelo (IfcProduct), los cuales a su vez pueden irse subdividiendo, llegando a las entidades más conocidas como p.ej. IfcSlab, IfcDoor, IfcFooting, etc.
La siguiente secuencia muestra un ejemplo de la anterior mencionada estructura jerárquica relativa a un elemento constuctivo tipo “viga”:
IfcRoot à IfcObject à IfcProduct à IfcElement à IfcBuildingElement à ifcBeam
Existen en el esquema IFC 2x3 unos 25 tipos de clases (entities) correspondientes a elementos constructivos del modelo.
Pero este no es el último nivel de profundidad en cuanto a la clasificación de elementos BIM que el esquema IFC nos proporciona.
Los elementos/componentes pueden pertenecer a una familia/tipologia concreta y cada uno de ellos incorpora una serie de atributos, como los que se muestran en el gráfico, los cuales acaban conformando el llamado Tipo (Type). Estas definiciones de tipo se refieren a elementos que aún no han sido insertados en la estructura del modelo (no contienen aún localización concreta). Se utilizan para especificar aquello común que van a compartir las distintas instancias alojadas en el proyecto y que ya incorporarán datos de posición concreta.
Si utilitzamos el ejemplo de un elemento compartimentador horizontal, en IFC se clasificaría como IfcSlab. Hasta ahí lo único que tenemos es una definición de un componente constructivo que nos aporta información en cuanto a su forma y relación espacial, pero poco más. Si queremos ahondar más en la clasificación de dicho elemento necesitaremos referirle al mismo el subtipo concreto que precisemos ( ¿ es un forjado, falso techo, rellano, cubierta plana ? ).
Para ello el IFC Schema incorpora una serie de atributos denominados Predefined Types, relacionables a nivel de elemento/componente (occurrences) y/o sus Tipos (Types), los cuales añaden una lista enumerada con un nivel adicional de jerarquía que nos permite diferenciar el elemento sin la necesidad de generar nuevas entidades.
Si seguimos el ejemplo del IfcSlab, refiriéndonos a su Tipo (Type) IfcSlabType, podemos obtener una lista de valores (IfcSlabTypeEnum) como la siguiente:
- Floor (por defecto)
- Roof (cubierta)
- Landing (rellano)
- Baseslab (losa o solera)
- Notdefined
- UserDefined: en caso de necesitar otro tipo de valor distinto de los que incorpora el listado, se designa este para que su valor sea anotado en otro atributo principal del IFC Schema, denominado ObjectType.
Existen también otros tipos de atributos del mismo estilo aplicables también a otro tipo de elementos como puertas o ventanas, p.ej., en los que ese nivel adicional de clasificación puede referirse a aspectos como el material o el sistema de accionamiento.
Ej: Puerta en IFC 2x3 (TC1)
OperationType a nivel de TIPO (Type)
IfcDoorStyle SINGLE_SWING_LEFT, SINGLE_SWING_RIGHT, DOUBLE_DOOR_SINGLE_SWING, DOUBLE_DOOR_SINGLE_SWING_OPPOSITE_LEFT, DOUBLE_DOOR_SINGLE_SWING_OPPOSITE_RIGHT, DOUBLE_SWING_LEFT, DOUBLE_SWING_RIGHT, DOUBLE_DOOR_DOUBLE_SWING, SLIDING_TO_LEFT, SLIDING_TO_RIGHT, DOUBLE_DOOR_SLIDING, FOLDING_TO_LEFT, FOLDING_TO_RIGHT, DOUBLE_DOOR_FOLDING, REVOLVING, ROLLINGUP, USERDEFINED y NOTDEFINED.
Como vemos, la cantidad de subtipos de puertas posibles es bastante amplia, sin tener que incorporar o crear parámetros nuevos no estandarizados.
2. Mapeado de clasificación BIM a Tipos Predefinidos IFC con ArchiCAD
Para que esta clasificación se convierta en un flujo de trabajo eficiente en nuestro día a día precisamos que nuestra herramienta de modelado BIM pueda acceder a ese nivel de edición del IFC Schema.
Aquí os mostramos de forma breve como ArchiCAD 21 permite eso y además automatiza su mapeado desde sistemas estandarizados de clasificación (Uniclass, Omniclass, Sfb…).
En este ejemplo utilizamos GuBIMclass V.1.2 ES ( www.gubimclass.org ) , sistema de clasificación BIM de elementos basado en la función principal de los mismos. En concreto mostraremos los pasos para una asignación en caso de exportación. Puede generarse también una automatización en el sentido inverso (no expuesto en este artículo) cuando importamos IFC, para que estos se asignen automáticamente a códigos de sistema de clasificación estándar en función de los tipos IFC del modelo externo.
En este ejemplo escogemos el código 40.20.10.10. Falsos techos interiores. Podríamos proceder con todos y cada uno de los ítems del sistema de clasificación.
En determinados proyectos donde cierto subtipos sean muy recurrentes, se puede incluso asignar un nivel superior de clasificación y añadir el USERDEFINED en caso de no encontrar el tipo de elemento que precisamos. En este ejemplo introducimos el Falso Techo Acústico como variante más específica.
Una vez hayamos configurado todo nuestro sistema de mapeado adaptado al sistema de clasificación deseado podremos proceder a generar nuestros IFC, asignando las MVD pertinentes y demás configuraciones para que en usos posteriores esta tarea quede totalmente automatizada. Pero esto último ya da para posteriores píldoras de buildingSMART Spanish Chapter.
Conclusión
Como vemos, el esquema IFC también nos da la posibilidad de incorporar a nuestros modelos la granularidad necesaria en cuanto a clasificación como para que sean capaces de soportar las tareas de chequeo o control de calidad requeridos en nuestros procesos BIM.
Quizás de esta forma, la próxima vez que tengamos dificultades en la clasificación de modelos ya no tengamos que atribuirlo al estándar abierto IFC, acostumbrado ya a recibir toda clase de improperios, y debamos buscar en otras fuentes el origen del problema.
Autor
David Delgado Vendrell, arquitecto por la ETSAV (Universitat Politècnica de Catalunya).
Gerente de DDV Arquitectura, micro-estudio de arquitectura y consultoria BIM. Se ha especializado en el uso de la plataforma ArchiCAD y su apuesta de implementación metodológica en BIM se basa en el uso de estándares abiertos, tambien llamado openBIM. Es miembro activo del Grupo de usuarios BIM de Cataluña (GuBIMcat) y socio de buildingSMART Spanish Chapter, a quien respresenta también en el IUG (International User Group) de buildingSMART International.
Colabora también en la Comisión "Construimos el Futuro" del ITEC en Cataluña, en respresentación del CoAC. Ha sido co-autor del sistema de clasificación BIM "GuBIMclass", iniciativa de GuBIMcat e Infraestructuras de Cataluña. Es beta-tester de la herramienta TCQ2000 del ITEC como experto en ArchiCAD y la interoperabilidad entre ambas plataformas.
Ha desarrollado tareas de beta-testing también para la herramienta BIMx de Graphisoft y el sistema Android.