Actualizado el 13 de enero de 2021
Introducción al concepto de clase
Cumpliendo con el objetivo que persigue cualquier estándar de regulación de una actividad, el estándar IFC (Industry Foundation Classes) ofrece un gran marco semántico que da respuesta y sentido a buena parte de las necesidades que se presentan durante el desarrollo de las actividades inscritas en el sector AEC y en general en el ámbito de la explotación inmobiliaria.
Descrito en la norma ISO 16739, en su concepción original, el estándar, tal y como reflejan sus siglas, define una colección de clases en las que es posible ordenar las diferentes entidades que son necesarias para el desarrollo y obtención de un activo inmobiliario. Ya en las bases de su creación el estándar está enfocado para ser usado en aplicaciones informáticas, por lo que todas las definiciones tienen su «traducción» a lenguajes interpretables por una máquina (EXPRES y XML).
 Ejemplo de expresión gráfica de lenguaje EXPRESS. Fuente: Wikipedia |
Al margen de su aplicación más directa en entornos informáticos, consideración que está fuera del alcance de este artículo, el estándar puede ser entendido con una gran enciclopedia de conceptos en donde se da sentido semántico a las actividades, procesos y entidades típicas de un proyecto arquitectónico. El estándar IFC es un gran diccionario de términos que, además, se va enriqueciendo y matizando en cada una de sus nuevas versiones que se publican y actualizan periódicamente.
Las clases del estándar IFC, entendidas como categorías o conjuntos de entidades con características comunes, han sido creadas de forma jerárquica definiendo un gran árbol de relaciones. La línea principal de este árbol se corresponde con aquella que describe los llamados objetos. Pero también podemos encontrar esquemas que definen propiedades, unidades de medida, materiales, geometrías y otras consideraciones que cubren de manera muy ambiciosa buena parte de las acciones típicas en el entorno de la arquitectura y construcción.
De esta manera, se crea una estructura de datos e información que nos permite situar los objetos en su clase y lugar correspondiente y además saber cuáles son sus orígenes, siempre en términos semánticos o conceptuales.
El estándar tiene por tanto una intención ontológica al pretender discernir cual es el origen de los elementos o de las cosas, siempre en el ámbito AEC. Esta consideración es la que convierte el esquema en complejo pero a la vez es la causa por la cual se ha instalado a nivel internacional como estándar de referencia.
El esquema se despliega desde su clase raíz, llamada IfcRoot, desarrollando diferentes líneas de clases en las que se van describiendo entidades de diferente naturaleza. Estas clases primarias ofrecen sentido semántico a conceptos que inicialmente son muy generales y en algunos casos también muy abstractos. Estos conceptos, siguiendo el símil de árbol, se situarían en el tronco principal y se van desarrollando y perfilando en clases cada vez más concretas y acotadas en su definición.
Este gran árbol de relaciones acaba desembocando en las clases finales, que podríamos entender como los frutos dados por el árbol y que han sido alimentados desde su base o raíz. Estas entidades finales normalmente son en las que se describen los elementos físicos o tangibles más reconocibles de un edificio como una ventana, una losa o una luminaria.
Las descripciones de estas clases son las que le dan al esquema su aplicación más práctica, ya que son las que se trasladan en las operaciones de exportación que se efectúan desde las plataformas de generación de los modelos de información.
Normalmente el esquema IFC es conocido por ser el referente en cuanto a criterios de clasificación de objetos, entendidos estos como elementos constructivos. Pero lo que quizá no es tan conocido es que en realidad el esquema de datos va mucho más allá y nos vas a permitir incorporar en su estructura otras entidades necesarias dentro del desarrollo de un proyecto y obra, como pueden ser procesos, actividades, agentes o roles. Todos ellos conceptos que se incrustan dentro de la línea de desarrollo de cualquier proyecto arquitectónico y los cuales vamos a tener la posibilidad de ordenar dentro de nuestro esquema general de datos.
Marco semántico
El concepto de clase, también entendido como contenedor o espacio de información, se construye a partir de una definición semántica. Esta definición, que encabeza todas y cada una de las clases que forman el esquema IFC, en algunos casos viene respaldada por una norma, como la ISO 6707-1 y en otras ocasiones son descritas a partir de la experiencia y consenso del comité de expertos que las han redactado. La precisión con la que está redactada la descripción de la clase es de verdadera importancia al determinar las condiciones que deben cumplir los objetos y otras entidades que se ordenen en su
interior.
 Ejemplo de definición semántica de la clase IfcBoiler (en castellano, caldera). Fuente: página oficial BS Standars |
La definición de las clases describe, de forma general, cuál es la función que deben cumplir las entidades o elementos que se ordenen dentro de ellas. También se incluyen dentro de la descripción cuestiones como la forma que suelen tener los objetos, la posición habitual que suelen ocupar en el espacio o la relación que tiene con otras entidades. En algunos casos, para favorecer el entendimiento de la definición, también se ponen ejemplos concretos. Las clases quedan identificadas con una definición particular y concreta pero a su vez quedan recogidas dentro de descripciones más generales que van a ser de aplicación común a otras clases que compartan funcionalidades comunes. Es decir, determinadas agrupaciones de clases tienen una herencia común.
A modo de ejemplo, se ilustra a continuación cual sería la herencia conceptual de la entidad IfcTask. En este caso, la herencia o árbol genealógico de esta clase tendría cuatro niveles. A saber, una IfcTask quedaría recogida dentro de la entidad IfcProcess, que a su vez quedaría dentro de IfcObject, que a su vez se ordenaría dentro del concepto de IfcObjectDefinition. Todas las entidades a su vez tendrían en común su origen más básico, el IfcRoot o Raiz.
 Ejemplo de herencia de concepto de la entidad IfcTask. Fuente: elaboración propia |
Este criterio de ordenación de la información va a ser de gran utilidad al permitir realizar acciones o tomar decisiones sobre conjuntos de elementos que compartan una misma herencia de concepto (Concept Inheritance).
Ejemplo de herencia de concepto de la entidad IfcDoor. Fuente: página oficial BS Standars
Así pues, cualquier elemento o entidad existente en nuestro proyecto arquitectónico va a quedar ordenada en alguna de las clases propuestas, de manera que estas entidades se adecuen y se las reconozca dentro de la definición dada. Además, vamos a tener la posibilidad de conocer su definición de concepto heredada.
Este primer nivel de ordenación de clases es primordial para que el estándar funcione y sea de verdadera utilidad. Su cumplimiento riguroso será el que homogenice proyectos desarrollados en diferentes países y diferentes culturas, creando un marco común de trabajo y un de lenguaje universal de comunicación.
Tipos predefinidos
Siguiendo el gran desarrollo ontológico que soporta al estándar IFC y completando el marco de identificación semántica que proporcionan las clases, el estándar ofrece una colección bastante generosa de los llamados tipos predefinidos.
Esta colección de recursos se ordena dentro de las clases de extensión TypeEnum y siempre están asociadas a las clases de objetos. Se presentan en forma de lista o enumeración. El objetivo de los tipos predefinidos es proporcionar una descripción más detallada de las clases que permita hacer una ordenación más precisa de los objetos. Es por ello que, al igual que sucede con las clases, para cada uno de los tipos propuesto se ofrece una descripción por lo general bastante detallada.
Como se ha dicho, los tipos predefinidos siempre están asociados a una clase. Dentro del sitio web oficial de la BS donde se accede al conjunto del estándar, podemos encontrar estos recursos situados en el epígrafe que ordena alfabéticamente todas las entidades del estándar, dentro de los llamados Enumeration Types.
 |
|
-Ordenación alfabética de los tipos predefinidos descritos en el estándar. Fuente- Página oficial BS Standars – |
Este listado de tipos predefinidos, también descrito en inglés, permite una ordenación de los elementos en segundo nivel de agrupación, siendo el primer nivel el de las clases. Este recurso nos ofrece la posibilidad de aplicar el estándar a niveles más concretos y por tanto conseguir así que uso sea más efectivo.
La colección de tipos predefinidos es de mucho interés y su uso sin duda es de verdadera importancia, al ampliar el marco semántico a niveles mucho más precisos que el que ofrecen las propias clases. A continuación mostramos varios ejemplos de clases con los tipos predefinidos descritos en el esquema.
 Ejemplo de clase y tipos predefinidos del esquema IFC de la clase IfcChiller. Fuente: elaboración propia |
 Ejemplo de clase y tipos predefinidos del esquema IFC de la clase IfcFooting. Fuente: elaboración propia |
 Ejemplo de clase y tipos predefinidos del esquema IFC de la clase IfcCostSchedule. Fuente: elaboración propia |
El propio esquema permite crear los llamados USERDEFINED, es decir, tipos predefinidos personalizados a las necesidades de la organización que los necesite, recogiendo definiciones más concretas que no se encuentren descritas en el esquema general. Como contamos un poco más adelante, esta consideración abre las puertas a la integración de otros estándares locales o específicos de las organizaciones, administraciones y empresas.
Propiedades y atributos
Podríamos entender que el primer paso necesario cuando introducimos objetos o entidades en un modelo de datos que define un proyecto de arquitectura, construcción o de operación y mantenimiento, es asegurarnos de que estos se encuentran bajo una estructura de agrupación predefina. Esta labor de ordenación de entidades es prioritaria y está en la esencia del estándar y también de la propia metodología BIM y su aplicación rigurosa será la base de una explotación de datos exitosa. Esta condición la conseguimos gracias a la estructura de clases y tipos que propone el esquema IFC y que se ha tratado en los puntos anteriores.
Una vez hemos garantizado que los objetos están estructurados de manera correcta, el siguiente paso es dotarlos de propiedades y atributos. Como no podía ser de otra manera, dentro del estándar vamos a encontrar una gran colección de parámetros que nos van a permitir enriquecer nuestro modelo de datos con variada información que tendrá como objetivo atender las diferentes necesidades que tenga la organización que esté utilizando el estándar, en cada una de las fases y para los distintos usos que queramos darle al modelo.
En la raíz del estándar (IfcRoot) se definen cuáles deben ser los atributos básicos comunes a todas las clases. Estos atributos permiten dotar de un nombre literal a los objetos (Name), un ID informático único y exclusivo (GlobalId) y de una descripción larga del elemento (Description). También vamos a poder identificar de quien es la autoría del objeto (OwnerHistory). Estos valores completarán la identidad básica de todos los objetos y su trazabilidad a lo largo del proceso de desarrollo del proyecto. Los parámetros proporcionados garantizan la identidad de los objetos, aunque en este caso el estándar no da respuesta a que criterios de nomenclatura se deben utilizar para la introducción de estos valores. Estas consideraciones quedarían recogidas en otros estándares internacionales o locales o serian de libre interpretación por parte de proyectistas o ingenieros.
 Ejemplo de identificación básica de una caldera (IfcBoiler). Fuente: elaboración propia |
En el ejemplo que nos ocupa, esta caldera ocuparía su lugar correspondiente dentro del esquema de clases descrito en el estándar.
 Ejemplo de ordenación de un objeto (caldera) dentro de su clase y tipo correspondiente, con la asignación de valores de los atributos básicos de identidad (GlogalId, Name y Description). Fuente: elaboración propia |
Una vez se ha asegurado la identidad básica de los objetos, el siguiente paso en el proceso de desarrollo de los mismos sería informar de cuáles son sus propiedades. Para ello la estrategia que sigue el estándar IFC es la creación de conjuntos de propiedades o los llamados Property Sets (Psets), también entendidos como paquetes de información o en términos informáticos como metadatos (datos de los datos).
Los Psets describen el tipo de información que se recogen en los parámetros ordenados dentro de ellos. Estos parámetros son los que van a dar respuesta a las necesidades de información asociadas a los objetos, espacios u otros conceptos generados en nuestro proyecto arquitectónico.
Existen conjuntos de propiedades específicos para cada una de las clases del esquema (Pset_Common), pero también existe un repertorio importante de ellos que son de aplicación común a diferentes clases. Estas propiedades, expresadas en forma de parámetros, vendrían a atender las diferentes necesidades de información que van a surgir a los largo del proyecto como podrían ser: análisis de costes, planificación temporal, coordinación 3D, ejecución de obra, demanda energética o explotación y mantenimiento.
Siguiendo el ejemplo que ilustra este apartado, una vez hemos identificado nuestra caldera y la hemos ordenado dentro de su clase y tipo correspondiente, llegaría el momento de enriquecerla con las propiedades que se prescriban como necesarias y que irán atendiendo los distintos requerimientos que se vayan dando a lo largo del proyecto.
 Asignación de conjunto de propiedades al objeto a través de conjunto de propiedades o Psets. Fuente: elaboración propia |
Sin duda la aplicación de estas propiedades básicas sería muy recomendable como información básica, aunque es lógico entender que en muchos casos será insuficiente para dar respuesta a las particularidades de los proyectos y a los condicionantes locales que tengan que cumplir. Para ello el propio estándar IFC anima a crear conjunto de propiedades personalizadas que den respuesta a las necesidades particulares de un proyecto en concreto, pero siempre respetando la estructura general de datos.
Al igual que sucede con los tipos predefinidos, podemos encontrar el listado completo de Psets dentro del esquema en el epígrafe que recoge ordenados alfabéticamente algunas de las entidades del estándar.
 Ordenación alfabética de los Property Sets descritos en el estándar. Fuente: página oficial BS Standars |
Valores predefinidos
Otro de los recursos muy valiosos y también desconocidos que ofrece el estándar IFC son valores predefinidos. Estos valores generalmente van asociados a alguna de las propiedades descritas y vienen a proponer diferentes valores que se suelen asignar a determinadas propiedades.
Esta consideración es de gran interés. En efecto, el valor de una propiedad en concreto suele tener un valor preestablecido, por lo que resulta de mucha utilidad recurrir a un listado concreto y elegir entre los valores propuestos siempre y cuando esto sea posible. De esta manera, estaríamos extendiendo la fidelidad al estándar (podríamos decir) hasta el último nivel, a nivel de valor.
Estos valores se recogen en la clase de extensión PEnum, y van asociados siempre a parámetros de propiedades incluidos en los Property sets. A diferencia de los propios PSets o clases, estas entidades no se muestran dentro del listado general alfabético, por lo que hay que buscarlos en las capas generales del esquema de Core data, Shared Elements o Domain Specific y siempre asociados a las propiedades de los objetos.
Por poner un ejemplo, hay un parámetro que es común a todas las clases de objetos y todos los Pset_Common. Este parámetro se denomina Status, y es de utilidad especialmente para proyectos de reformas o de actualizaciones, aunque también puede ser usado en obra nueva. Determina cual es la condición temporal de los elementos dentro del desarrollo de la intervención. En este caso, el posible valor del parámetro no tendría mucha interpretación, por lo que se ofrecen cuáles serían las posibles opciones que se podrían usar dentro de una lista.
 Listado de posibles valores para asignar al parámetro Status. Fuente: página oficial BS Standars |
La incorporación de estos listados de valores dentro de los softwares de modelado es del todo recomendable al reducir el margen de incertidumbre y facilitar así la introducción de información de origen reglado.
Integración de estándares
Hemos visto en los apartados anteriores como el propio estándar IFC deja espacios para la integración de otros estándares. Los tipos predefinidos serian un ejemplo de integración de estándares locales. En este nivel de agrupación, las organizaciones o empresas que quieran incorporar el estándar IFC pueden integrar los estándares propios de los que ya disponían y que por necesidades operativas no pueden perder.
Esta labor de integración pasaría por equiparar o mapear las principales categorías con las que estas organizaciones han estructurado su información tradicionalmente e igualarlas con las clases IFC. Este trabajo de mapeado debe hacerse con mucho criterio, ya que estaría en juego la validez de los estándares usados por las empresas que quieran actualizarse. Por tanto, esta tarea de integración debe ser realizada por expertos en gestión de información dentro de entornos BIM.
 Proceso de mapeado entre clases IFC y clases y categorías locales. Fuente: elaboración propia |
En consecuencia, se debe partir de esta base: las clases oficiales de IFC pasarían a definir la base general de información que estructure cualquier modelo arquitectónico. Asumiendo esta nueva estructura general, también la de los tipos predefinidos en el estándar, la incorporación de estándares locales se tendría que hacer mediante la incorporación de tipos personalizados que queden integrados en las clases IFC con la mayor coherencia posible y asegurando el menor conflicto con la descripción semántica de las clases.
 Ejemplo de integración de tipos personalizados dentro de una clase de IFC. Fuente: elaboración propia |
Igualmente, cuando hablamos de propiedades ya hemos visto que cuando las propuestas en el esquema son insuficientes, vamos a tener la posibilidad de crear nuestra propia colección de parámetros, agrupadas en PSets personalizados. La única condición que debe cumplir esta colección de propiedades personalizadas es que se apliquen a las clases generales descritas en el esquema.
 Ejemplo de asignación de conjunto de propiedades a una clase IFC. Fuente: elaboración propia |
Con este procedimiento aparentemente sencillo (aunque no tanto en la realidad de las empresas), estaríamos integrando estándares de construcción y arquitectura de toda índole respetando siempre la estructura general propuesta por el IFC.
Idioma
El idioma en el que está escrito y descrito el estándar es el inglés. Este idioma es dominante en buena parte de los estándares internacionales y debemos aceptar su uso como idioma original, con o sin traducción mediante. Esta consideración no es menor y, al margen de reflexiones que pueden derivarse de su aplicación y que tienen que ver con una dominancia cultural evidente del mundo anglosajón en el terreno tecnológico, su uso debe ser bajo nuestro punto de vista indiscutible.
 Inglés, idioma internacional de intercambio |
|
|
Al hilo de esta cuestión podemos afirmar que para ser fieles al estándar debemos mantener el idioma original en el que fue creado, muchas veces con matices o detalles que podríamos considerar como intraducibles. Por eso, tanto la denominación de clases y tipos como los atributos de identificación y propiedades de los objetos deben permanecer en inglés.
Para algunas entidades existe una traducción propuesta dentro del estándar a otros idiomas como el francés, alemán o japonés. Esto sucede también con las propiedades. La traducción se hace normalmente sobre el nombre de la clase, y también de la descripción de los parámetros de propiedades. Esta traducción a día de hoy no existe de manera oficial al castellano.
Asumiendo que el inglés es la lengua común intercultural, podríamos admitir que la información introducida en el modelo, alojada en las clases y parámetros correspondientes, sea en el idioma nativo del lugar en el que se esté desarrollando el proyecto. Esta condición puede ser válida en proyectos de ámbito estrictamente local. En muchas ocasiones, esta consideración tampoco va a ser posible especialmente si el proyecto tiene carácter internacional y por tanto el idioma ingles será el impuesto para cualquier dato introducido en el modelo.
Existe una iniciativa en la BSSC que ha traducido al castellano buena parte de las clases definidas en el estándar, tanto la clase como la definición que la acompaña. También se encuentran traducidos un listado de Tipos y de Conjuntos de propiedades (Psets). Sin duda disponer de esta traducción al castellano es positivo y se debe entender como un soporte para aquellas comunidades que no dominen con soltura el inglés, aunque insistimos en que creemos firmemente que el idioma de intercambio debe ser el inglés.
También está disponible para los usuarios de este estándar el denominado bsDD, que es uno de los 3 estándares que desarrolla y custodia la Building Smart junto con el IFC y el IDM (Information Delivery Manual).
Este servicio permite integrar dentro de los modelos la clasificación de las entidades de IFC y además toda la colección de Property set y propiedades descritas en el estándar. El recurso permite conocer la traducción de las entidades originales en ingles a otros idiomas.
Conclusiones
Ha sido mi intención con esta entrada del blog destacar la importancia que tiene la semántica dentro del estándar IFC, en realidad dentro de cualquier estándar en general y por qué no decirlo, en cualquier ámbito de la vida misma.
Si bien es cierto que la lectura de las definiciones incluidas en el esquema se hace a veces un poco dura, especialmente en los conceptos más iniciales del esquema y por tanto más abstractos, merece la pena hacer el esfuerzo, y si es posible en el idioma original, en este caso el inglés. Esta lectura ayuda a fijar conceptos asociados al ámbito de la arquitectura y construcción que conducen a un mejor entendimiento de los procesos y entidades. Sin duda es una gran ayuda para ordenar ideas a los que ya tenemos un cierto bagaje pero también para los que se inician en el ámbito del sector inmobiliario.
Hay que tener en cuenta que en su redacción han participado expertos internacionales con gran conocimiento y capacidad de abstracción y síntesis, por lo que podemos considerarlo como un documento perfectamente consolidado y que además es custodiado y “mimado” por sus miembros, generalmente muy activos y vocacionales.
A día de hoy todavía hay muchos conceptos por publicar dentro del esquema, como en general todo lo relativo a obra civil (puentes, carreteras, ferroviarios) y aeropuertos, pero lo que ya está descrito cubre buena parte de las necesidades que se pueden dar a lo largo del desarrollo de un proyecto arquitectónico. Por tanto, en sucesivas actualizaciones veremos como el esquema se expande con nuevas clases que permitan alojar entidades que hoy en día no tienen donde ser ubicadas.
En cuanto al idioma, debemos asumir el inglés como idioma de referencia. Podríamos entender que su uso está en la capa más fundamental del desarrollo y aplicación exitosa del estándar. Las traducciones solo se pueden entender como soporte o guía de apoyo pero entendemos que nunca pueden ser alternativas al idioma original. Cualquier traducción, por precisa y de calidad que sea, desvirtúa el estándar y en realidad deja de hacerlo efectivo.
Para saber más…
- Building Smart. The home of BIM. Pagina Oficial de la Building Smart
- Industry Foundation Classes (IFC)
- IFC en español. Building Smart Spanish Chapter.
- Formato IFC y Open BIM. Blog BibLus de accasoftware.
- Entendiendo el IFC. Blog de BIMlevel. Iván Guerra.
- IFC (Industry Foundation Classes). BondBryan Blog
- ¿Que es el IFC?. Blog de BIMskills. Explicación en 1 minuto de Antonio Tort.
- Estándar para la creación de objetos eCOB. Estándar creado por el ITEC (Instituto de Tecnología de la Construcción de Cataluña).
- IFC, formato BIM universal. Podcast de BIMRRAS con David Delgado Vendrell.