Temario M6T2

Tema 2.
Estándares e
interoperatibilidad BIM, formato
IFC, COBIE, BUILDING SMART
Docente autor: Nombre del docente

Tema 2. Estándares e interoperatibilidad
BIM, formato IFC, COBIE, BUILDING
SMART
ÍNDICE
1. EVOLUCIÓN DE LAS HERRAMIENTAS QUE TRABAJAN EN BIM ................................................................ 5
1.2.- Clasificación del software que trabaja en entorno BIM. ................................................................... 15
2.- INTEROPERATIBILIDAD ............................................................................................................................. 17
2.1.- INTEROPERATIBILIDAD SINTACTICA .................................................................................................. 17
2.2.- INTEROPERATIBILIDAD SEMANTICA .................................................................................................. 18
2.3. MÉTODOS DE INTEROPERATIBILIDAD ................................................................................................ 19
2.3.1. ENLACES ENTRE SOFTWARE PROPIO............................................................................................... 19
2.3.2.- ENLACES DE SOFTWARE DE SINTACTICA ABIERTA ......................................................................... 19
2.3.3.- IFC Y ESTANDARES ABIERTOS ......................................................................................................... 20
2.3.4.- ESTRUCTURA DE LA INFORMACIÓN ............................................................................................... 22
2.3.5.- OTRAS SOLUCIONES DE INTEROPERATIBILIDAD ............................................................................ 24
2.4.- CONCLUSIONES ................................................................................................................................. 24
3.- FORMATO IFC ........................................................................................................................................... 25
3.1.- ¿POR QUÉ IFC? .................................................................................................................................. 26
3.2.- ¿QUE CONTIENE EL ARCHIVO DE INTERCAMBIO? ............................................................................ 27
3.3.- USO DEL IFC EN DISEÑO Y CONSTRUCCIÓN ...................................................................................... 27
3.4.- ¿COMO ES LA ESTRUCTURA DE IFC? ................................................................................................. 28
3.5.- IFC COMO FORMATO DE ARCHIVO, ALTERNATIVAS ......................................................................... 29
3.6.- VERSIONES......................................................................................................................................... 30
3.7.- FILTROS INTELIGENTES ...................................................................................................................... 31
3.8.- ¿POR QUE LOS MVD SON IMPORTANTES? ....................................................................................... 32
3.9.- IFC COMO UN FORMATO DE ARCHIVO GENERAL ............................................................................. 33
3.10.- IFC COMO FORMATO “AS BUILT” .................................................................................................... 33
3.11.- IFC COMO FORMATO DE ENTREGA ................................................................................................. 33
3.12.- CONCLUSIONES ............................................................................................................................... 34
4.- COBie ........................................................................................................................................................ 35
4.1.- ¿QUE ES COBIE? ................................................................................................................................ 35
4.2.- ¿POR QUE USAMOS COBIE? .............................................................................................................. 35
4.3.- ¿QUIEN DESARROLLA COBie?............................................................................................................ 37
4.4.- MODO DE TRANSFERENCIA DE TECNOLOGIA ................................................................................... 37
MBIMMA_M6T2_161005
3
SMART
4.5.- DESCRIPCIÓN DEL ARCHIVO .............................................................................................................. 38

4.6.- APLICACIONES ................................................................................................................................... 39
4.7.- CONCLUSIONES ................................................................................................................................. 40
5.- BUILDINGSMART ...................................................................................................................................... 42
5.1.- INTRODUCCIÓN ................................................................................................................................. 42
5.2.- LA ALIANZA INTERNACIONAL POR LA INTEROPERATIBILIDAD .......................................................... 42
5.3.- IFC 1.0 ................................................................................................................................................ 43
5.4.- HOJA DE RUTA DEL IAI ....................................................................................................................... 44
5.5.- BUILDINGSMART ............................................................................................................................... 45
6.- CONCLUSIONES ........................................................................................................................................ 49
BIBLIOGRAFIA ................................................................................................................................................ 50
MBIMMA_M6T2_161005
4
SMART
1. EVOLUCIÓN DE LAS HERRAMIENTAS QUE

TRABAJAN EN BIM
El éxito del sistema de Modelado de Información de la Edificación se base en tres partes:
• La gente
• El proceso
• La tecnología
Más allá de concentrarnos en los procesos vamos ahora a entender la evolución de las
herramientas BIM
1.1.- UNA BREVE HISTORIA DE LAS HERRAMIENTAS DE

ENTORNO BIM
BIM no es un concepto nuevo, la siguiente sentencia describe perfectamente una

herramienta BIM actual:
“The architect next beguins to enter a series of specifications and data-a six-inch slab floor,
twelve-inch concrete walls, eight feet high within the excavation, and so on. When he was
finished, the revised scene appears on the screen. A structure is taking shape. He examines it,
adjust it… These lists grow into an evermore-detailed, intelinked structure, which represents
the maturing thought behind the actual design”
Augmenting Human Intellect, Douglas C. Engelbart, 1962,
http://www.dougengelbart.org/pubs/augment-3906.html
MBIMMA_M6T2_161005
5
SMART
Como podéis comprobar describe un escenario en el que los datos de los edificios se
introducen por medios computacionales y se comprueba el resultado, y como veis estamos
hablando de un estudio realizado hace más de 50 años.
El principio del diseño basado en objetos, la manipulación paramétrica, las bases de datos
relativas, las conexiones con el GIS, y el modelado sólido, aparece entre mediados de la década
de los 60 y principio de los 70, del pasado siglo. Uno de los primeros proyectos con uso
completo de las bases de datos vinculadas a la arquitectura para la constitución de los
diferentes componentes, fue el Building Description System (BDS) https:
//archive.org/details/ERIC_ED113833,
En cuya introducción dice lo siguiente:
“Muchos de los costes de diseño, construcción y utilización de los edificios se derivan de la

dependencia a los dibujos como descripción del mismo. Como sustituto, este documento
describe el diseño de un sistema informático útil para almacenar y manejar información de
diseño, hasta el último detalle que el propio diseño permita, también la construcción y el
diseño funcional.
Consideramos un edificio como la composición espacial de un conjunto de piezas. El sistema

denominado Building Description System (BDS), tiene los siguientes puntos asociados:
1. Un sistema simple para introducir datos gráficos complejos.
2. Un lenguaje grafico interactivo para editar y componer conjuntos de elementos.
3. Capacidades gráficas para producir perspectivas o dibujos ortográficos de alta

calidad.
4. Un tipo y capacidad de formato que permite la clasificación de la base de datos por

atributos, por ejemplo: tipo de material, proveedor, o componer un conjunto de datos para el
análisis.”
MBIMMA_M6T2_161005
6
SMART
Este programa usaba componentes de bibliotecas individuales, un interface de usuario

gráfico, y una ventana grafica que mostraba perspectivas y vistas ortográficas y un buscador de
bases de datos que permitía encontrar fácilmente cualquier elemento del proyecto.
BDS, fue creado por el profesor Charles Eastman

http://www.cc.gatech.edu/computing/Database/faculty/eastman.html , (actualmente Director
del Digital Building Laboratory, Georgia Tech School of Architecture). Hasta después del año
1.974 Eastman había estado proclamando que los dibujos para la construcción eran ineficaces,
principalmente por culpa de la duplicidad. También criticó que el archivo de originales en papel
de un edificio, quedaba rápidamente obsoleto por la imposibilidad de recoger en tiempo todas
las modificaciones posteriores que los edificios pudieran tener y así mismo la falta de solidez de
dichos originales que van perdiendo calidad con el tiempo.
Sus conclusiones fueron, que el BDS, podría reducir el coste del diseño, sobre trazado de
planos, más de un 50 %.
Aunque su uso fue únicamente de naturaleza experimental y no fue usado en proyectos

reales de una manera constante, se pudo predecir e identificar muchos de los problemas
fundamentales que nos encontramos hoy en día en la puesta en marcha del BIM. Nos daremos
cuenta de la importancia de esto si pensamos, que fue creado siete años antes que Autodesk
fuera fundada y 25 años antes de la primera versión de Revit.
En 1.977 Avions Marcel Dassault https://es.wikipedia.org/wiki/Dassault_Aviation creó un

software capaz de desarrollar la geometría de los caza Mirage. Dicho software fue denominado
CATI (Concepción assistée Tridimensionnell Interactive), y posteriormente fue redenominado
CATIA (Computer Aided Three-dimensional Interactive Application) en 1.981. Posteriormente
en 1.984 Boeing eligió CATIA V·, como su principal herramienta en CAD 3D.
MBIMMA_M6T2_161005
7
SMART
El término “Building Model” fue utilizado por primera vez por Robert Aish,
https://www.autodeskresearch.com/people/robert-aish en su documento “Building Modelling:
The key to integrated construction CAD”
Robert Aish fue creador de los componentes Generativos con Bentley System en 2.003 y
actualmente trabaja como investigador en Autodesk. Aish ha trabajado con SMG en RUCAPS,
fue un pionero en la eliminación temporal en los procesos de construcción que se usó en el
proyecto de la etapa tres de la terminal de Heathrow, curiosamente, veinte años más tarde, se
usó BIM para el proyecto de la etapa cinco de dicho aeropuerto. Habitualmente se cita dicho
proyecto como uno de los pioneros en el uso del BIM.
El Centre for Integrated Facility Engineering (CIFE), se fundó en la Universidad de Stanford

en 1.988 por Paul Teicholz, centrando el desarrollo en los modelos de construcción en 4
dimensiones, al añadir el parámetro tiempo a los atributos del modelo constructivo.
Además del desarrollo descrito en Europa y Estados Unidos, a la vez se está produciendo un
desarrollo similar dentro del bloque soviético. Gabor Bojar,
http://europeanbimsummit.com/es/mr-gabor-bojar-founder-of-graphisoft-will-be-in-the-
european-bim-summit15-2/ un físico de Budapest (Hungría) comienza a trabajar en lo que se
convertiría en 1.982 en ArchiCAD, Gabor escribió el código inicial en los ordenadores de Apple
de contrabando a través del telón de acero. El Software, que se llamaba Radar CH, era similar en
concepto al BDS pero escrito en el sistema operativo de Apple. Radar CH, se convirtió en
ArchiCAD y fue el primer software BIM escrito para poderse usar en ordenadores personales.
MBIMMA_M6T2_161005
8
SMART
Casi al mismo tiempo que Grafisoft comenzaba a vender Radar CH, se funda The
Parametric Technology Corporation (PTC), PTC, lanzo la primera versión de
Pro/ENGINEER en 1.988.
MBIMMA_M6T2_161005
9
SMART
En 1.990 General Dynamics Electric Boat Corp. Eligio CATIA para diseñar el
submarino de la Armada de los EE UU. Virginia.
El término “Building Information Model”, fue utilizado por primera vez en 1.992 por
G.A. van Nederveen y F. Tolman, https://thebimhub.com/2014/03/16/building-
information-modelling/#.V-lbV_CLTcs en el artículo “La automatización en la
construcción”.
A la vez en 1.992 y con motivo de los Juegos Olímpicos de Barcelona, Frank O. Gehry
diseño la escultura del pez, las limitaciones financieras y de planificación obligaron a
James M. Glymph, un socio de la firma, a buscar un programa informático que facilitara
el proceso de diseño y construcción, lo que llevaría a la adopción de CATIA. La escultura
fue modelada íntegramente en 3D y la información que se entregó a los fabricantes fue
dicho modelado en 3D.
MBIMMA_M6T2_161005
10
SMART
Pero este no es ni siquiera el primer ejemplo de prefabricación digital en la

construcción. Doce años antes en 1.970 Leslie Robertson,
https://en.wikipedia.org/wiki/Leslie_E._Robertson , creo un proceso continuo para
todas las piezas prefabricadas integrantes de la construcción del Word Trade Center, casi
todas las piezas de la estructura de acero, estaban descritas a partir de tarjetas
perforadas producidas por IBM
Para los paneles, el tamaño y dimensiones de cada una de las placas, cada soldadura,
cada perno, se proporcionaban sus parámetros mediante tarjetas perforadas. De hecho,
los pliegos de contratación de cada uno de los cuarenta contratistas que tomaron parte
no estaban basados en planos si no en las propias tarjetas perforadas. Probablemente
fue la primera vez que el diseño de un edificio de gran altura se proporcionó en formato
digital.
MBIMMA_M6T2_161005
11
SMART
En 1.997 Irwin Jungreis http://www.csail.mit.edu/user/2095 y Leonid Raiz

http://rize3d.com/team/leonid-raiz se separaron de PTC y fundaron su propia compañía de
software llamada Charles River Software en Cambridge, Massachusetts. En 2.000 habían
MBIMMA_M6T2_161005
12
SMART
creado un software llamado Revit, Revit incorporaba un motor de cambios paramétricos.

Charles River Software, fue absorbida por Autodesk en 2.002.
En 1.997 Dennis Sheldon se unió a Frank O. Gerhy and Associates. En 2.002 Sheldon,
Gerhy y James Glymph fundan Gerhy Technologies, creando una versión personalizada de
CATIA AEC al mercado denominada Digital Project.
En 2.011 Trimble Navigation compra Tekla. Tekla era bien conocido por su software de
cálculo y comprobación de estructuras de Acero inoxidable X-Steel, que estaba muy
consolidado en el mercado, esto facilito el interés de su principal competidor. StruCAD Tekla
tenía una base importante dentro del mundo BIM y fue fundada en 1.966, el nombre es una
abreviatura de las palabras finlandesas Teknillinen laskenta, que significa calculo técnico.
MBIMMA_M6T2_161005
13
SMART
Siempre es difícil predecir el futuro, pero es posible que los modelos se conviertan en
instrucciones de programación, y que el compartir archivos en la nube es lo que está
actualmente en auge.
Estoy seguro que el sistema BIM va a provocar una revolución en la representación y

análisis de los proyectos. Fácilmente los Ayuntamientos podrán tener software adaptado
para comprobar las condiciones urbanísticas, etc. Podrán gestionar grandes archivos con
modelos BIM de los edificios del municipio, creando una especie de google earth, con los
datos de todos los edificios, etc. Pero todo esto entra dentro de la especulación, tendremos
que esperar a ver cómo esta nueva manera de trabajar va cambiando el modelo de la
construcción.
Aunque siempre hay que ser escépticos con las predicciones de futuro, sobre todo las
tecnológicas:
 “Los ordenadores en el futuro podrán pesar no más de 1,5 toneladas”. Popular mechanics
1949.
 “Creo que no hay un mercado mundial para más de cinco ordenadores”. Thomas Watson,
chairman of IBM, 1943
 “No hay ninguna razón para que nadie quiera un ordenador en su propia casa”. Ken Olson,
presidente y fundador de DEC.
MBIMMA_M6T2_161005
14
SMART
1.2.- Clasificación del software que trabaja en entorno BIM.

A pesar de que estamos hablando de tecnología basada en entorno BIM, no está de más recordar
estos puntos:
 No es software ni tecnología, (es un proceso posible debido a la tecnología)
 No se puede comprar en una caja
 No es un 3D, elegante
 No es algo que un técnico de CAD hace de forma aislada
BIM, como una mezcla de Simulación, Gestión de la información y tecnología para el intercambio de
información.
BIM TRATA FUNDAMENTALMENTE SOBRE COMPARTIR

INFORMACIÓN ESTRUCTURADA
MBIMMA_M6T2_161005
15
SMART
La tecnología es importante en los procesos BIM, y debe estar bien clasificada en todas sus distintas
formas, sin embargo no hay una plataforma única adecuada a todas las tareas requeridas en la
construcción.
La tecnología BIM se puede clasificar de la siguiente forma:
Muchas de las herramientas BIM del mercado están basadas en la generación de geometría, sin
embargo la Colaboración o capacidad de compartir información estructurada es uno de los
principios fundamentales del BIM.
MBIMMA_M6T2_161005
16
SMART
2.- INTEROPERATIBILIDAD
En un principio la interoperatibilidad podría ser definida como la capacidad de diversos sistemas y
organizaciones para trabajar conjuntamente (inter-operación)
El término es frecuentemente usado en sentido técnico, pero puede ser usado en un sentido más
amplio, dentro de entornos sociales o políticos, es simplemente los factores de organización los que
influyen para que el sistema funcione, no el entorno.
INTEROPERATIBILIDAD FUNDAMENTALMENTE ES LA IDEA DE

COMPARTIR INFORMACIÓN ESTRUCTURADA
Hay fundamentalmente dos tipos de interoperatibilidad:
 Interoperatibilidad sintáctica
 Interoperatibilidad semántica
2.1.- INTEROPERATIBILIDAD SINTACTICA

La palabra “sintáctica” etimológicamente está compuesta de dos partes:
 Σύν: (syn): significa: acuerdo
 Τάξις: (táxis): significa: ordenar
Sintaxis es:
 El estudio del modo en que se combinan las palabras y los grupos que estas forman para
expresar significados, así como las relaciones que se establecen entre todas esas unidades.
 Conjunto de reglas que definen las secuencias correctas de los elementos de un lenguaje.
Si dos o más sistemas son capaces de comunicarse e intercambiar datos, están mostrando una
interoperatibilidad sintáctica.
Es decir, para que dos sistemas sean capaces de comunicarse, deben expresar lo mismo de la
misma manera, para que puedan entenderse, las normas que rigen estas comunicaciones es lo que
denominamos sintaxis. No solo a nivel computacional, sino en todos los tipos de comunicación.
MBIMMA_M6T2_161005
17
SMART
Para que exista una Interoperatibilidad sintáctica debe haber:
 Formatos específicos de datos
 Protocolos de comunicación.
Es obvio que para que dos sistemas se puedan comunicar y compartir datos, estos tienen que estar
en un formato específico que ambos sistemas puedan entender, y por otra parte, no sirve de nada
que los formatos sean compatibles si las comunicaciones se realizan de una manera no organizada,
los sistemas además de compartir los formatos, deben recibir y emitir dicha información con una
ordenación determinada, para que el receptor pueda procesarla de una manera correcta.
2.2.- INTEROPERATIBILIDAD SEMANTICA

Semántica viene de la palabra griega “σημαντικός”, que significa “significado”
Semántica es:
 La relación entre significado, como palabras, frases, signos o símbolos y su denotación: lo

que expresan.
Más allá de la capacidad de los sistemas computacionales de intercambiar datos, la

interoperatibillidad semántica es la capacidad de interpretar dicha información de una manera,
llena de significado y exacta, para producir resultados utilizables.
El contenido de la información no debe contener ambigüedades.
Para entenderlo vamos a trasponer un pasaje del Hobbit de JRR Tolkien, que ilustra este tema
perfectamente:
“-Buenos días- Dijo Bilbo, y eso es lo que quería decir. El sol brillaba, la hierba estaba muy verde.
Pero Gandalf mirándole desde detrás de las pobladas cejas, que sobresalían más allá del ala de su
sombrero:
-¿Qué quieres decir?- Dijo – “Me deseas una buena mañana, o quieres decir que es una buena
mañana, lo quiera o no; o que te sientes bien esta mañana; o que es una mañana para sentirse
bien.”
Lo que Bilbo dijo y lo que Gandalf entendió pueden ser dos cosas totalmente diferentes.
MBIMMA_M6T2_161005
18
SMART
Como veis, aunque sintácticamente los datos estén perfectamente estructurados los dos sistemas
tienen que tener la capacidad de comprender en la misma línea ambas estructuras, de nada sirve
seguir los protocolos de datos si luego los significados son diferentes.
2.3. MÉTODOS DE INTEROPERATIBILIDAD

2.3.1. ENLACES ENTRE SOFTWARE PROPIO
La interoperatibilidad se desarrolla únicamente entre determinados productos, que son
compatibles entre sí, pero no entre todos los productos del mercado, que quedarían excluidos.
Vamos a ver el siguiente ejemplo, OASYS, http://www.oasys-

software.com/products/engineering/gsa-suite.html ha desarrollado un plug-in para Revit, que
permite exportar modelos GSA desde Revit, y leerlos directamente dentro de un lector GSA sin
pasar previamente por una traslación en 3D.
Pero este modelo de intercambio no es compatible con otro software de modelado u otro software
de análisis estructural. De hecho si actualizamos Revit u OASYS, el plug-in necesita actualizar el
archivo de intercambio.
2.3.2.- ENLACES DE SOFTWARE DE SINTACTICA ABIERTA

Hay varios formatos de traslado que permiten comunicarse a distintos software:
 DXF. (drawing Exchange format)/ dwg. Desarrollado originalmente por Autodesk, ha llegado
a ser un estándar universalmente reconocido para el intercambio de geometrías. (puntos,
líneas, mallas poligonales) junto con capas y colores.
 IGES (Initial Graphics Exchange Spec) es más sofisticado que el DXF y permite el modelado
de sólidos incluidos NURBS (Non-uniform rational b-splines, and free for surfaces).
 STEP (Estándar for the Exchange of Product model data)
STEP es importante, debido a que el estándar IFC está basado en el, STEP e IFC se consolidan como
futuros protocolos dentro del mundo de la construcción, STEP es un estándar ISO y es el sucesor de
IGES. Se concibió en principio para ser un archivo único con toda la información del proyecto,
independientemente de la información que este llevara, sería un registro principal para los modelos
integrados y una base para la actualización de los modelos.
MBIMMA_M6T2_161005
19
SMART
Es interesante destacar que STEP se desarrolló el año 1.984, mucho antes de que se empezará a
hablar de BIM.
2.3.3.- IFC Y ESTANDARES ABIERTOS
La IFC (Industrial Fundation Class) es una archivo de intercambio abierto y libre desarrollado por la
buildingSMART (http://www.buildingsmart.es/) es una asociación sin ánimo de lucro y no
controlada por ninguna empresa desarrolladora de software, cuyo objetivo es fomentar la eficacia
en el sector de la construcción a través de estándares abiertos de interoperatibilidad. La última
versión del archivo IFC es 2x4, (comúnmente denominada IFC 4). Es un formato de datos de
especificación abierta. IFC es un formato de archivos basado en objeto, que la facilita al
interoperatibilidad en la industria de la construcción, y se usa habitualmente como formato de
intercambio BIM. Es importante comprender que las intercomunicaciones se basan en metadatos
no en datos geométricos
Las clases y objetos IFC representan un modelo de información tanto geométrico como
alfanumérico, formado por un conjunto de más de 600 clases y en continua ampliación. Todos los
programas de software que soportan IFC pueden leer y escribir información e intercambiarla con
otros programas.
BuildingSMART es sinónimo de BIM y IFC. Fue creada en 1.994 y llamada originariamente IAI
(Industry Alliance for Interopertatibility) con 12 miembros americanos. Fue posteriormente abierta
a otras nacionalidades en 1.995 y 1.997 cambio su nombre por el de International Alliance for
Interoperatibility. El espíritu con el que fue creado IAI era el de generar beneficios por la
interopertibilidad del software dentro de la industria de la construcción, en todas y cada una de las
partes interesadas. En 2.005 fue rebautizada como BuildingSMART.
IFC es probablemente el más conocido “Open Standar” de interoperatibilidad dentro de la industria

de la construcción. Los “estándares abiertos” son imprescindibles para el funcionamiento de la
interoperatibilidad y tienen siempre que ser gratuitos y que no impliquen sobrecoste en el proceso
de interoperatibilidad. La idea que subyace es que los programadores de software individuales usen
MBIMMA_M6T2_161005
20
SMART
dicho estándar para desarrollar sus productos. Si el software desarrollado usa el protocolo común
definido por el estándar abierto, tendrán la interoperatibilidad incluida en su diseño.
La competitividad será posible debido a:
 Calidad de la implementación
 El interface del usuario
 La facilidad de uso
 Las prestaciones
 El precio
Siempre que los datos estén intactos serán transferibles a través de la interoperatibilidad. Una
empresa podrá, en principio, intercambiar su información de un colaborador a otro, sin pérdidas ni
desplazamientos de datos, independientemente del programa de usa, que este colaborador use.
Aunque el estándar abierto, puede a veces no ser entendido por las casas de software como algo
interesante, debido a que facilitan el uso de software de la competencia.
El formato IFC está registrado por las normas ISO como ISO/PAS 16739 y actualmente está en
proceso de ser reconocido como un estándar internacional como ISO/IS 16739.
El IFC es un formato estructurado para facilitar las tareas dentro de la industria de la construcción.
 Los productos (IfcProduct) están divididos en elementos espaciales (IfcSpace), elementos

físicos (IfcBeam), análisis estructurales, etc.
 Los productos contienen información sobre el material, su representación (geometría),

localización, e información cuantificada.
 Los procesos (IfcProcess) contienen información sobre tareas, sucesos y procedimientos. Los
procesos se pueden asignar a los productos.
 Los recursos (IfcResources) contienen información acerca de materiales, mano de obra,

equipos, etc.
IFC es un modelo de relaciones entre las entidades.
 IfcWall (elemento del edificio)
 IfcExtrudedAreaSolid (geometría)
 IfcCartesianPoint (Construcción básica)
MBIMMA_M6T2_161005
21
SMART
Las entidades raíz contienen los siguientes puntos:
 IfcObjectDefinition (Tipos y definiciones)
 IfcRelationship (Relaciones entre objetos)
 IfcPropertyDefinition (propiedades del objeto)
Hay cantidad de software, que tiene capacidad de leer y escribir IFC.
Las especificaciones que tiene que cumplir un software para ser calificado como IFC, están
rígidamente especificadas en la introducción del V2.0 proceso de certificación, regulado por la
BuildingSMART.
Podéis consultar los software y los paquetes que han recibido la certificación en la siguiente página
web: http://www.buildingsmart-tech.org/certification/ifc-certification-2.0/ifc2x3-cv-v2.0-
certification/participants
2.3.4.- ESTRUCTURA DE LA INFORMACIÓN

La estructura del modelo es muy importante, porque afecta en general a todos los datos del
modelo a lo largo del desarrollo del proyecto.
La figura representa todos los datos generados en un proyecto. Los cuadros coloreados representan
a los diferentes colaboradores que tienen responsabilidades en la información. Para este ejemplo
vamos a asumir, que la parte del arquitecto es la amarilla, la parte del ingeniero estructural es la
azul y las instalaciones son la roja.
MBIMMA_M6T2_161005
22
SMART
En la vista segunda x, señalamos la zona gris como ejemplo de información necesaria para un
determinado contratista, que solamente necesita cierta información arquitectónica y cierta
información estructura, pero nunca el modelo completo. A veces el arquitecto necesita información
de la que es propietario el calculista de las estructuras.
En la vista tercera y, aparece una nueva zona a través de la información, por ejemplo el calculista de
la estructura requiere algún tipo de información que es responsabilidad del arquitecto u otras
informaciones que es propiedad de otros contratistas.
En estas graficas comprendemos que las diferentes agentes intervinientes tienen diferentes
responsabilidades dentro del modelo, necesitan autorizaciones de otros agentes para poder
desarrollar su trabajo. La información debe estar estructurada de manera que facilite el
intercambio de información independientemente del agente autor de la misma. Y además se debe
compartir de manera que dicha información esté en condiciones óptimas para desarrollar el trabajo
correspondiente. Este tema se vuelve más complicado si consideramos las interfaces entre
disciplinas.
Por ejemplo, si programamos un hueco en una viga para permitir el paso de instalaciones. El
responsable de instalaciones debe responsabilizarse del tamaño y situación del hueco. Pero el
ingeniero calculista debe responsabilizarse de actualizar el hueco y rehacer los cálculos
estructurales teniéndolo en cuenta.
Las herramientas que actualmente usamos en la industria de la construcción afecta a la capacidad

de estructurar y compartir la información. Uno de los puntos clave es la elección de los distintos
software, para que la compatibilidad sea la más adecuada.
Para la elección se debe tener en cuenta las siguientes cuestiones:
 ¿Saben las empresas de software lo que realmente necesita cada uno de los diferentes
agentes en cuanto a software?
 ¿Son todos los datos realmente compatibles?
 ¿Los diseñadores, manejan el software de una manera adecuada para utilizar todo su
potencial en cuanto a interoperatibilidad?
Actualmente los software solo funcionan a través de un formato que traducen a IFC, por lo que
debemos de cuestionarnos lo siguiente:
 ¿Podrán el software de recepción hacer la transmisión de los datos según sus propias
necesidades?
 ¿Está toda la información necesaria incluida en el archivo de intercambio?
MBIMMA_M6T2_161005
23
SMART
 ¿En caso de la información que no esté incluida, se añadirá solo al archivo de intercambio?
No existe un único software, que realice todas las operaciones necesarias para el correcto
desarrollo del proyecto. Por lo que el archivo de intercambio es una buena solución. Pero el IFC
simplemente es una especificación de archivos, por lo tanto solo es una parte de la solución. La
solución total deberá contar con otros componentes:
 Las habilidades de las distintas tecnologías.
 Las infraestructuras de las redes
 Las habilidades especificas del software
 Los procesos
 Las necesidades de los negocios
 La gente.
2.3.5.- OTRAS SOLUCIONES DE INTEROPERATIBILIDAD

El IFC es un trabajo en desarrollo. Como resultado tanto diseñadores como Ingenieros, actualmente
tienen que rellenar los huecos, que dicho formato deja entre las aplicaciones, como hemos visto
anteriormente.
Hay otras opciones para mejorar la interoperatibilidad, cuando el IFC no provee de la funcionalidad
requerida o que el proyecto demanda.
 COM/API (Component Object Model/Application Programming Interface)

(https://msdn.microsoft.com/en-us/library/aa389276(v=vs.85).aspx)
 SDK (Software Development KIT) (https://developer.microsoft.com/es-

es/windows/downloads/windows-10-sdk)
La mayor desventaja es que requieren conocimientos profundos de programación, habilidades que

los diseñadores, arquitectos e ingenieros carecen, ya que no se provén en ninguna etapa de sus
formaciones.
2.4.- CONCLUSIONES
MBIMMA_M6T2_161005
24
SMART
Si BIM es un proceso basado en compartir información estructurada, entonces colaboración e

interoperatibilidad son base en el desarrollo del proceso.
BIM no es una tecnología, pero es un proceso basado en la tecnología. En el mismo sentido la

colaboración tiene que ser facilitada y reforzada por el uso de la tecnología apropiada, pero la
tecnología no puede compensar las deficiencias en los bloques de trabajo que bloquean la
colaboración.
Las tecnologías estudiadas que permiten la colaboración son:
 Extranet/EDMS
 Integradores del modelo (Model Integrators)
La interoperatibilidad es un desafío clave para la implementación de los sistemas basados en los

procesos BIM, Hemos estudiado diferentes posibilidades en cuanto al desarrollo de la
interoperatibilidad, fundamentalmente el estándar IFC, IFC empieza a funcionar, pero todavía
encuentra dificultades en su uso. El proceso de certificación basado en IFC va mejorando basado en
el BuildingSMART, es cierto que la presencia de una certificación no es garantía automática de
interoperatibilidad.
El problema básico no consiste en las especificaciones propias del formato IFC, sino como dicho
formato se pone en práctica en cada uno de los software y la calidad de la ejecución de los
interface.
En el caso de que IFC no pueda ser el marco adecuado de interoperatibilidad podemos recurrir a
otras tecnologías, lo que implicaría conocimientos prácticos de programación.
LECTURAS RECOMENDADAS:
 http://www.architectureresearchlab.com/arl/2011/08/21/bim-history/
 http://www.slideshare.net/EEPaul/construction-collaboration-2010
3.- FORMATO IFC

Hemos visto que el formato IFC, es un formato de intercambio, BIM en el que las entidades se
clasifican en clases y es un estándar abierto con facilidad ser leído y escrito por los principales
programas de entorno BIM.
MBIMMA_M6T2_161005
25
SMART
El uso fundamental del formato IFC es compartir datos entre las distintas aplicaciones de software
que nos ayuden a completar nuestro trabajo.
Un dato de alguna de las fases del proyecto del edificio podría ser usado es cualquier etapa
posterior y necesitaría una reentrada, en la cadena de datos BIM, es por ello que los formatos de
intercambio, en este caso IFC cobra una importancia vital en el desarrollo de los procesos BIM.
IFC, sea probablemente el principal factor de para impulsar la implementación de los procesos BIM.
Es la única alternativa real a la estandarización y sobre todo a la interoperatibilidad de la manera
que la hemos expuesto en páginas anteriores. Su uso debe ser impuesto por los agentes de la
construcción en todos los proyectos, sin importar, clientes, tamaños, presupuestos, etc.
Es el punto donde hay que insistir y desarrollar en cualquier estrategia que se base en el traspaso
de información, y al mismo tiempo el formato IFC es objeto de malos entendidos y variantes como
veremos más adelante.
3.1.- ¿POR QUÉ IFC?

Actualmente el uso de herramientas BIM está en aumento. Para aprovechar adecuadamente los
beneficios del intercambio de información se requiere que en los BEP se detallen las condiciones en
los que estos intercambios se deben producir. Los clientes deben saber expresar adecuadamente
las condiciones que requieren en el desarrollo del edificio. También debemos tener en cuenta que
actualmente hay muchas variaciones en las calidades de los software dedicados a la importación o
exportación de datos. La mayoría necesitan una configuración personalizada. Debemos tener en
cuenta que a su vez el formato IFC tiene puntos fuertes y puntos débiles. Es decir hay determinados
ámbitos en los que el formato IFC es inmejorable, pero hay otros en los que el intercambio de datos
MBIMMA_M6T2_161005
26
SMART
no es todo lo correcto que se necesitaría. Para lograr el éxito en el proceso se debe ir más allá de un
entendimiento básico de la norma IFC y mantenerse al día de las novedades que se generan.
3.2.- ¿QUE CONTIENE EL ARCHIVO DE INTERCAMBIO?
El modelo IFC contiene tanto geometría como datos del edificio, contiene todos los datos o un
subconjunto de la información contenida en los archivos nativos del programa correspondiente. La
transformación y la exportación de los datos nativos en un archivo IFC es una forma de transferir
datos de una aplicación a otra. El formato de intercambio es abierto, libre y suficientemente
documentado. Al proporcionar las interfaces IFC el suministrador de software demuestra que se
ajusta a la norma de BuildingSMART y que la aplicación es capaz de proporcionar
interoperatibilidad con cientos de herramientas BIM.
3.3.- USO DEL IFC EN DISEÑO Y CONSTRUCCIÓN

El uso del IFC es común en las fases de diseño y construcción hoy en día. En diseño se utiliza en
aplicaciones de visualización y detección de conflictos. Los equipos de diseño tienen la facilidad de
unir o hacer referencias a los distintos modelos independientemente de la aplicación en la que se
hayan desarrollado, de la misma manera que anteriormente se intercambiaban los archivos DXF en
las aplicaciones CAD anteriores. Además de hacer referencia a modelos de otras disciplinas los
archivos IFC se utilizan para importar datos de una aplicación a otra. Tanto los datos generales,
MBIMMA_M6T2_161005
27
SMART
como las geometrías, como las tablas, pueden ser perfectamente exportados desde una aplicación
de origen y luego ser importados a otra aplicación para continuar con el diseño o el análisis. En el
proceso de transferencia puede haber pérdida de datos, como veremos más adelante.
El tener un modelo virtual en un formato abierto también es una ventaja para los contratistas que
pueden ver y comprobar el desarrollo del diseño con programas fáciles de usar, sin necesidad de
conocimientos de modelado y hacer mediciones o tablas de programación basadas en el modelo
virtual del edificio.
Además de la situación de integración entre las herramientas BIM, una gran cantidad de
herramientas que usan el formato IFC están evolucionando. Ejemplos de ellas son herramientas de
aseguramiento de la calidad, los visualizadores del modelo, programaciones, listados de
verificaciones, etc.
3.4.- ¿COMO ES LA ESTRUCTURA DE IFC?

Hemos explicado que el modelo contiene datos tanto geométricos (3D) datos específicos (2D).
Técnicamente el formato se define como un modelo de entidad-relación basado en “EXPRESS”.
Para explicarlo mejor vamos a basarnos en un ejemplo, sobre la puerta.
Un elemento de puerta se define como una puerta en el sistema, Al ser una puerta ya está
clasificada en el dominio del edificio (llamadas familias en Revit, por ejemplo). Hay definiciones de
tipo que nos permiten colocar puertas similares en el mismo proyecto y compartir la misma puerta
en proyectos distintos. Tanto el tipo como el ejemplar tienen atributos y propiedades adjuntas, lo
hemos visto ya. Esto es lo más importante, se adjunta la información común como las instrucciones
de mantenimiento, el número de modelo, tamaño, etc. Pero también adjuntas información
específica del ejemplar como número de serie, fecha de instalación, condiciones, etc.
Las propiedades tienen una estructura específica. Las propiedades se agrupan en conjuntos.
Algunos de estos conjuntos se especifican en la norma IFC, algunos están definidos en el BEP del
proyecto, por ello hemos hablado siempre que la información es estructurada. No tiene sentido
introducir datos sobre, por ejemplo, el color de la puerta en el conjunto de datos que hacen
referencia a su fabricante, etc.
Hay otra forma de crear agrupaciones de elementos, de lo que hemos hablado es de agrupaciones
de propiedades, pero también se crean dentro del modelo agrupaciones de elementos, por ejemplo
sistemas en los modelados de elementos MEP. Dichos sistemas tienen propiedades comunes del
sistema, que se extienden a todos sus elementos, (tipo de fluidos, material de los conductos, etc).
MBIMMA_M6T2_161005
28
SMART
IFC también define las relaciones entre los elementos de construcción. Entre ellas los sistemas MEP
a los que hemos hecho referencia. Otras relaciones describen como los componentes unitarios se
van ensamblando para la creación del edificio. Las relaciones incluyen la estructura espacial (como
está compuesto el conjunto, edificios independientes, número de plantas, habitaciones (espacios),
y como los espacios se agrupan en zonas). Otras relaciones establecen las conexiones y ubicaciones
de estos elementos de la estructura espacial, esto es algo importante para los Facility Manangers.
3.5.- IFC COMO FORMATO DE ARCHIVO, ALTERNATIVAS

IFC, Es en su forma más común un archivo de texto ASCII, el esquema define como el texto se
convierte en aplicaciones de objetos y define las relaciones entre los objetos y sus propiedades
inherentes. Incluso como archivo de texto, se pueden desarrollar aplicaciones que lean y
transformen dichos textos en archivos útiles. El Archivo IFC se basa en el estándar ISO 10303-21
llamado “STEP-file”.
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63141.
MBIMMA_M6T2_161005
29
SMART
El formato de archivos IFCXML utiliza el mismo modelo de datos que el formato IFC normal, pero en
lugar de una representación ASCII el archivo se representa como un documento XML. Tener el
archivo con este formato puede facilitar el traslado de la información entre distintas máquinas.
También facilita notablemente la consulta de los datos directamente en el archivo. Sin embargo
estos usos no se han ganado actualmente una adopción generalizada y no se utiliza
adecuadamente, por lo menos hasta la fecha, lo que no quiere decir que en un futuro no se
implemente.
Dado que los archivos IFCXML e IFC son archivos de texto y contienen gran cantidad de datos, son
los principales candidatos para la implementación de la interoperatibilidad y para la compresión de
ficheros. Con el uso de la herramienta “zip” o “rar” normalmente se llega a conseguir una
compresión entre el 80 y el 90% de disminución del tamaño del archivo. IFCZIP se ha estandarizado
como el formato de archivo en el que se usan determinados algoritmos de compresión, que
solamente pueden ser usados en archivos IFC, por lo que se puede llegar a compresiones mayores,
lo único es que no está lo suficientemente implementado.
3.6.- VERSIONES
El esquema del formato IFC es libre en diversas versiones y está en constante evolución. Las
versiones que actualmente se utilizan son la IFC 2x3 y 4 (la denominación puede ser un poco
confusa, así que vamos a dar una pequeña explicación. Históricamente las versiones han ido
denominándose progresivamente 1.0, 1.5, 1.5.1, posteriormente aparecieron las versiones 2x; 2x2;
2x3, posteriormente a esta aparece la versión 2x4, que ha simplificado su denominación a 4, la
próxima versión se denominara 5).
A pesar de que la versión 2x3, es anterior a la actual, es la más utilizada y lo será probablemente en
un futuro próximo. La razón de esto, es que las distintas plataformas de software necesitan un
tiempo para actualizarse a dicha versión, por lo que hay una especie de retraso, entre que aparece
una nueva versión hasta que es totalmente operativa. También es verdad que los proyectos que se
están desarrollando en un momento dado, no pueden cambiar fácilmente de versión, por la
cantidad de agentes implicados, lo que aumenta la inercia de las versiones anteriores y retrasa la
aplicación de las nuevas versiones del formato.
La aparición de nuevas versiones se debe fundamentalmente a que la plataforma BuildingSMART

recoge todas las limitaciones y problemas que los formatos han podido dar en su aplicación y que
los usuarios le hacen llegar, por lo que estas quejas, comentarios, etc, BuildingSMART trata de
tenerlos en cuenta en el desarrollo de las distintas versiones.
MBIMMA_M6T2_161005
30
SMART
IFC4 está ampliando la generación de geometrías y parámetros, ha extendido los servicios de

construcción y modelado estructural, e incluye un formato XML más simple.
IFC5 es la nueva versión próxima a aparecer. Actualmente se encuentra en fase de planificación, así
que no tenemos fecha prevista de aparición. Se espera que la principal ventaja de esta versión sea
expandir aún más las capacidades paramétricas y la inclusión del ámbito de la infraestructura.
3.7.- FILTROS INTELIGENTES

El objetivo del formato IFC es generar un esquema común para el intercambio de todos los datos
entre herramientas BIM. Sin embargo no todos los datos son necesarios para este intercambio
entre dos herramientas. La información requerida depende del proceso de intercambio, siendo
parte de toda la información. Este subconjunto de información es lo que se denomina MVD (Model
view definition). Vamos a describir esto con ejemplos.
El formato IFC2x3 es actualmente el formato de intercambio más utilizado, el tipo de uso que los
MVD permiten en este formato es un valor muy genérico. Es utilizable para combinar los distintos
modelos para visualización y detección de conflictos. En el caso de la versión IFC4 dichos puntos de
vista del modelo se han subdivido en dos, como veremos más adelante.
Es importante pensar que los MVD tienen complementos opcionales y dependen de la

configuración de las herramientas BIM, estos complementos puede que no estén incluidos en la
herramienta en su configuración por defecto y debamos cargar como elementos independientes.
Por ejemplo Space Boundary, añade un punto de vista nuevo a las relaciones espaciales entre
elementos. El principal objetivo de este plugin es la consecución de análisis energéticos y térmicos,
pero también por añadidura nos permite identificar y colocar objetos determinados en los espacios
correctos, por ejemplo a la hora de recurrir a su mantenimiento .
MBIMMA_M6T2_161005
31
SMART
Configuración de la exportación al formato IFC, herramienta de Revit común. Los ajustes de

exportación están concordantes con las especificaciones MVD y los ajustes que introduzcamos
tendrán una respuesta en el contenido y estructura del fichero IFC.
El uso de MVD en el formato IFC4 se ha remplazado por dos usos distintos en la vista de referencia.
Estos subconjuntos se adecuan más a los esquemas de flujo de información que utilizan modelos de
referencia. El arquitecto con su herramienta BIM genera un modelo que traslada en archivo IFC, se
traslada solamente un subconjunto de elementos a cada uno de los colaboradores en el diseño,
para apoyar su proceso de trabajo (coordinador de diseño, detección de conflictos, visualización,
extracción de mediciones, etc). Pero lo importante es que los colaboradores no van a realizar
ninguna modificación en el archivo original, sino que van a emitir solicitaciones de cambios, ya que
no tienen facultad para reformar dicho archivo, esto lo van a hacer mediante ficheros BCF o similar.
También hay posibilidades en el archivo IFC Design Transfer View, este esquema nos permitirá
proveer un modelo en el que el colaborador podrá gestionar y modificar partes del modelo,
teniendo una mayor responsabilidad en el mismo, pudiendo así introducir modificaciones, para
mejora de los sistemas o resolución de conflictos.
3.8.- ¿POR QUE LOS MVD SON IMPORTANTES?

El uso de un subconjunto (MVD) recorta y reduce los modelos hasta hacerlos más eficientes, y de esta manera, al elegir
un subconjunto de una manera correcta, nos aseguramos de que la información que nos llega es la que nosotros
necesitamos y que no viene interferida con otra información que no es necesaria para nuestro trabajo. El uso de MVD
también nos protege en los problemas legales que pudiéramos tener, y los trabajos no quedan expuestos, el autor
MBIMMA_M6T2_161005
32
SMART
mediante el MVD, protege su propiedad intelectual, teniendo un control absoluto de la información que realmente
publica, preservando el resto.
3.9.- IFC COMO UN FORMATO DE ARCHIVO GENERAL

Las características descritas anteriormente hacen que el IFC sea un formato de archivo de
intercambio, de gran valor, y pueda ser un candidato a un estándar aceptado por todos los
intervinientes en el modelo. Por un lado el IFC es un formato abierto, libre y gratuito, puede ser de
amplio uso a nivel mundial y puede ser apoyado por una amplia gama de aplicaciones. También es
gestionado y regulado por la norma ISO, siendo hasta ahora un formato bastante estable, con pocas
variaciones, lo que le hace compatible no solo con las versiones actuales de los programas de
software, sino con versiones anteriores y versiones futuras. Es posible gracias a todo esto que el
archivo de un modelo en formato IFC pueda ser usado en el futuro, con todas sus posibilidades de
almacenamiento de información.
3.10.- IFC COMO FORMATO “AS BUILT”

A pesar de todas las ventajas descritas del formato IFC, todavía hay partes de información que no
se trasladan correctamente desde el software correspondiente, lo hemos mencionado al hablar de
las posibles versiones posteriores, por lo que puede ocurrir que cualquier técnico de
mantenimiento que posteriormente vaya a analizar y abrir un archivo IFC del edificio se encuentre
con lagunas en la información, en comparación con el traslado de la versión nativa del proyecto
formato RVT por ejemplo.
Para resolver el problema, actualmente se recomienda el archivo de las dos versiones del modelo,
el archivo nativo que lee el programa de modelado, RVT u otro, y el formato IFC, para reducir el
riesgo de pérdida de la información. En general se considera que el archivo nativo tendrá más
validez a corto plazo, ya que las versiones posteriores suelen transformar sin problemas los
archivos creados en versiones anteriores. En cambio el archivo IFC tendrá más valor a largo plazo,
ya que la estructura de la información como ya hemos visto no va a cambiar, y su validez va a
permanecer a lo largo del tiempo.
3.11.- IFC COMO FORMATO DE ENTREGA

El IFC tiene una buena base para ser un formato de entrega y formar la base de una estrategia
integrada de transferencia de información. Los modelos BIM, en sus formatos nativos tienen como
hemos visto gran cantidad de datos divididos en geométricos y no geométricos (propiedades y
MBIMMA_M6T2_161005
33
SMART
cantidades). Con una adecuada transferencia del modelo BIM tanto el propietario del edificio como
los responsables del mantenimiento tienen una base adecuada para crear una representación
virtual del edificio real que sirva para apoyo de los procesos necesarios posteriores a la
construcción del mismo. También la estructura propia de dichos modelos nos sirve como
marcadores para localizar exactamente cada uno de los elementos descritos dentro del edificio. Los
esfuerzos de normalización, nos van a permitir usar las herramientas con una seguridad y garantía
superiores a la actual y el uso de los modelos BIM va finalmente a imponerse como ayuda para el
mantenimiento y Facility Managment del edificio.
También tenemos que tener en cuenta que el proceso que hemos descrito de traspaso de la
información desde el modelo que nos ha servido para construir el edificio al modelo que nos va a
servir para su mantenimiento debe ser complementado con los datos correctos de las
modificaciones introducidas posteriormente a su entrada en uso. Por lo que el formato IFC no pasa
a ser un formato únicamente de lectura, sino un elemento modificable, por los software concretos
que puedan usarse para la gestión del mantenimiento.
3.12.- CONCLUSIONES
El IFC es un formato que se utiliza para describir los datos de construcción y geometría de un
edificio a través de las disciplinas de construcción y a través de las distintas fases del ciclo de vida
del edificio. El formato es un estándar abierto y a la vez regulado por normativa ISO. Cuenta con el
apoyo de la mayoría de la industria de la construcción y está respaldado por una organización
global sin fines lucrativos. Es un requisito imprescindible para la interoperatibilidad BIM y la
mayoría de las herramientas de modelado y gestión del modelo son compatibles y admiten la
importación/exportación del formato.
Un archivo IFC es una exportación propia de una herramienta BIM y sirve para que otra
herramienta distinta pueda leerlo y compartir la información contenida en el modelo, ya sea para
coordinación del modelo, el traspaso de información en fase de diseño, o para el intercambio de
datos requeridos en la interoperatibilidad.
Existen diferentes versiones, la versión actual de uso generalizado es la IFC2x3, pero se espera que
se generalice la versión IFC4, en los próximos años.
Cuando se exportan datos a un formato IFC, se puede filtrar los datos creando un subconjunto de
los mismos y exportar dicho subconjunto únicamente, es lo que se denomina MVD.
Es cierto que actualmente el formato IFC no resuelve plenamente todos los problemas de
interopertibilidad, pero se está trabajando para reducir dicha problemática.
MBIMMA_M6T2_161005
34
SMART
4.- COBie
4.1.- ¿QUE ES COBIE?
COBie (Construction Operations Building information Exchange)
Datos del producto

As Built
Etiquetas, números de
serie
Garantias
Repuestos
• DISEÑO • USO/MANTENIMIENTO
• CONSTRUCCION
Espacios
Sistemas y
equipamientos
Es principalmente y formato de intercambio de datos, para la interoperatibillidad, pero a diferencia

del IFC, está centrado en datos de información, no en datos geométricos, esto es debido a que el
uso principal de dicho formato es el mantenimiento y uso del edificio, no su construcción, (Facility
Managment). Esta obviamente relacionado con el estándar BIM, que es el que va a crear este
archivo. Fue creado por Bill East https://www.linkedin.com/in/williameast
COBie, es un registro de datos del edificio, para su uso en el Facility Managment, incluye colocación
en el punto de origen, listas de equipamiento, tablas de planificación de productos, garantías, etc,
listas de piezas de repuesto y programas de mantenimiento preventivo.
4.2.- ¿POR QUE USAMOS COBIE?
MBIMMA_M6T2_161005
35
SMART
A la finalización del proyecto, el Project Manager, suministra a la propiedad un camión de cajas de

cartón, rellenas de papel con toda la información de la construcción del edificio, incluyendo una
caja de planos, en los que consta la etiqueta de “As Built”, a veces para que la carga no se distribuya
en un camión, se adjunta en PDF en varios Cds o en un Pendrive, etc. Se supone que toda esta
información es la necesaria para que el gerente de mantenimiento del edificio la use para realizar
sus funciones, es frecuente que ni abra las cajas, ni vea siquiera lo que tienen los cds, por dos
motivos fundamentales, la cantidad de información es tan grande y no está correctamente
compilada, por un lado y por otro los planos definidos como “As Built”, frecuentemente están
plagados de errores o son simplemente los de proyecto, con sello nuevo .
Esto claramente no es de ayuda para la gestión del mantenimiento.
Si queremos crear información realmente utilizable, deberemos trabajar doblemente, de una

manera clara debemos rehacer la totalidad del proyecto, adjuntando la información pertinente de
cada uno de los elementos colocados realmente, si lo analizamos correctamente llegaremos a la
conclusión de que es como hacer el proyecto dos veces. Por ejemplo el constructor debe recorrerse
pausadamente el edificio construido para recabar los números de serie de los elementos colocados
en el mismo, dato que en el proceso constructivo no ha recabado o ha perdido entre la cantidad de
papeles.
No se utiliza la mayoría de la información creada en fase de ejecución al no ser útil en la fase de

mantenimiento, para crear información necesaria para el mantenimiento, deberíamos hacer un
trabajo importante de horas, recabando información sobre proveedores de equipos, garantías,
piezas de repuesto en los sistemas de mantenimiento, distribuidores de dichas piezas, gestión de
MBIMMA_M6T2_161005
36
SMART
los activos, planes de mantenimiento preventivo y personalizados, etc. Datos que no se han
gestionado ni recopilado en la fase de construcción al no ser importantes en dicha fase.
Si se ha partido de un modelo BIM, las especificaciones COBie identifican el contenido de dicha

información y donde debe ser recabado y colocado, reduciendo la producción de documentación
en papel. El diseñador o proyectista define los espacios, los sistemas, los tipos de equipamiento,
posteriormente el contratista o el constructor completa la información con los datos concretos del
equipamiento, marca, modelos, número de serie y adjunta la información del fabricante, garantía y
piezas de repuesto, el agente de puesta en marcha ofrece datos de plan de trabajo, instrucciones
de funcionamiento, formación necesaria para su utilización, etc.
4.3.- ¿QUIEN DESARROLLA COBie?

La National Aeronautics and Space Administration (NASA) y la White House Office of Science and
Technology Policy, presentaron las dos primeras aplicaciones de este proyecto en 2.005. El Facility
Maintenance and Operations Commitee of the National Institure of Building Sciences, formó un
equipo de proyecto que representa a diseñadores, constructores, propietarios, agentes de puesta
en marcha y a las empresas de software para identificar las necesidades que los intercambios de
información, necesarios durante la construcción para el traspaso de información, iban a demandar.
Entre 2.005 y 2.009 COBie ha pasado de ser una idea inicial de un estándar internacionalmente
reconocido a ser implementado en el software comercial en todo el mundo. El desarrollo del
proyecto COBie ha sido dirigido desde el Engineer Research and Development Center, Construction
Engineering Research Laboratory. Un laboratorio dependiente del cuerpo de ingenieros de la
armada estadounidense.
4.4.- MODO DE TRANSFERENCIA DE TECNOLOGIA

La tecnología COBie se transmite a través de múltiples canales de actividad, los principales son los
siguientes:
 Desarrollado en los pliegos de condiciones que los contratos administrativos requieran

cuando estos se realizan con la administración
 Creación de instrucciones y datos de ayuda para mostrar a los contratistas como deben
aplicar la información y recogido en los contratos.
MBIMMA_M6T2_161005
37
SMART
 Coordinar con los organismos de normalizaciones nacionales o internacionales para

asegurarse de que los contenidos de los archivos COBie cumplen los estándares de
interoperatibilidad.
 Coordinación con asociaciones profesionales y comerciales para asegurar que se cumplen

los requisitos impuestos por la estandarización COBie
 Actualización periódica de los archivos COBie, para evitar su obsolescencia y que estén
siempre totalmente vigentes.
 Publicar plantillas, guías y contenidos técnicos relacionados con el National Institute of

Building Sciences (NIBS) o consultar en la página web http://www.wbdg.org para facilitar la
más amplia difusión de esta norma.
4.5.- DESCRIPCIÓN DEL ARCHIVO

COBie es un formato basado en la especificación (PDF 6.2 MB) para compartir información sobre las
instalaciones de los edificios. Hay dos tipos de recursos que se incluyen en el fichero COBie, por una
parte datos de los equipos, por otra parte datos de los espacios. Puede ser que los datos específicos
de los equipos, los pueda suministrar el fabricante de distintas maneras, COBie nos ayuda a que los
datos del equipo concreto colocado en fase de ejecución, venga en un formato electrónico
compatible y consolidado, sin ningún tipo de recopilación de información por parte del receptor.
Los datos facilitados pueden ser importados directamente en CMMS o cualquier software de
gestión de mantenimiento de edificación, sin coste alguno. Los archivos PDF, de dibujo y la
información del modelo del proyecto de construcción que se acompañe, se organizan de tal modo
que sea fácil su acceso a través de los directorios de un servidor externo seguro.
Si bien los detalles técnicos del formato COBie pueden parecer complejos, el formato no está
destinado a usuarios finales. COBie lo que ofrece en realidad es un servicio de intercambio de datos
o sistemas de información de espacios y equipos sin la intervención de ningún usuario, asegurando
la integridad de la información entre programas y equipos. Si pensamos que la información que se
integra dentro de cualquier ordenador se basa en códigos ASCII es evidente que nosotros como
usuarios, de procesadores de textos, de hojas de cálculo, etc. No tenemos la necesidad de dominar
dicho lenguaje. Podemos establecer la misma similitud, COBie no es más que un lenguaje de
intercambio de información entre plataformas, no es necesario conocer a fondo COBie para
valernos de la herramienta. Si tenemos que conocer la herramienta a la que transformamos los
archivos.
MBIMMA_M6T2_161005
38
SMART
Para hacer COBie lo más práctico posible, está disponible en varios formatos, el Software usado
para el diseño y desarrollo del proyecto podría utilizar el estándar STEP Physical File Format (ISO
10303 part 21), que son como hemos visto anteriormente archivos IFC (Industry Foundation Class).
COBie se basa en la normativa (ISO 16739). Se puede visionar un archivo COBie, y comprobar sus
datos directamente, sin usar archivos complejos de traslado de información, pasando directamente
los datos de COBie a una simple hoja de cálculo. Existen además plantillas para los archivos COBie,
fácilmente descargables.
Asimismo podemos tener un listado de los software disponibles que utilizan el estándar COBie
http://www.nibs.org/?page=bsa_cobiemm
4.6.- APLICACIONES
Al igual que en cualquier otro contrato, en los contratos de diseño y construcción la calidad del
producto recibido depende de la capacidad del diseñador o contratista para cumplir las
especificaciones estipuladas. Antes de la existencia de COBie, la necesidad de definición clara de la
calidad de los datos proporcionados, era escasa. Sobre todo porque la acumulación de dichos datos
sobre soporte papel hacían casi inviable una revisión en profundidad de los mismos en el momento
de traspasarlo a la propiedad al finalizar la construcción.
MBIMMA_M6T2_161005
39
SMART
El Estándar COBie ofrece la posibilidad de comprobar automáticamente la concordancia de los

documentos electrónicos de traspaso, es seguro que los propietarios comprenden la importancia
de la implantación de los sistemas COBie de traspaso de información.
Hay tres decisiones en el desarrollo de un proyecto que la propiedad puede tomar para asegurarse
un control de la información a través de COBie. La primera es especificar en el contrato las
clasificaciones utilizadas para los datos CMMS, COBie utiliza por defecto el sistema de clasificación
OmniClass, proporcionado por el Construction Specifications Institute. http://www.omniclass.org/ .
La siguiente decisión a tomar es la limitación de los datos o conjunto de información, para que
únicamente se suscriba a los bienes que en realidad necesitan ser gestionados, de esta manera
reducimos de una manera importante el volumen de información que pueda ser recabada. Y por
último el propietario debe identificar claramente las propiedades específicas que se demandan
para cada uno de los elementos incluidos. En este caso la posición por defecto es que los datos
demandados sean los que completen las tablas de planificación de los modelos. En la mayoría de
los casos la necesidad de información es superior a la ofertada por los niveles de detalle
contratados en el programa de modelado.
Desde el punto de vista del diseñador, podemos decir que los datos COBie son simplemente los
datos que aparecen en las tablas de planificación anexas a un modelo BIM. Cualquier Software de
diseño, comprende la necesidad de la exportación de los datos en COBie y busca la compatibilidad
de formatos. Por ello debemos asegurarnos el funcionamiento correcto del software y las
configuraciones que tiene en la exportación de los datos a COBie.
Desde el punto de vista de los contratistas, la aportación a los datos en COBie, solo le ayuda para
cotejar que los datos están introducidos y no se va a duplicar información en el modelo, para luego
preparar dichos datos en la exportación a software de gestión de mantenimiento. Si la información
COBie está bien estructurada, se puede de una manera automática completar dicha información y
producir manuales de mantenimiento automáticamente.
https://www.youtube.com/playlist?list=PL9E7A408B074B90C9&feature=viewall
4.7.- CONCLUSIONES
Está claro que una de las partes importantes de la implantación del sistema de gestión de proyectos
basado en los modelos BIM es el traspaso y la posibilidad de compartir la información que es algo
que hemos denominado anteriormente interoperatibilidad, esto es posible gracias al uso de
MBIMMA_M6T2_161005
40
SMART
formatos que se puedan crear a partir de software de modelado y como en este caso se pueda leer
por el software de gestión. Anteriormente hemos visto que el formato IFC permite el traslado
completo del modelo entre distintos software de desarrollo del proyecto. Pero no habíamos
entrado en la fase de uso del edificio. Para ello tenemos el formato COBie, este formato no es tan
completo como el IFC, ya que discrimina el tipo de información y, como hemos visto, no usa la
información de la geometría, porque no la necesita.
El formato COBie, se utiliza y esta creado para la intercomunicación entre los programas de
modelado y diseño BIM del edificio y los programas de gestión de mantenimiento, por lo que
únicamente traslada los datos utilizables en la gestión del mantenimiento del edificio. Depurando el
resto.
http://www.nibs.org/mpage/0612_COE_COBie
http://www.wbdg.org/resources/cobie.php
MBIMMA_M6T2_161005
41
SMART
5.- BUILDINGSMART
5.1.- INTRODUCCIÓN
En un estricto sentido la industria de la construcción, ha funcionado de la misma manera durante
muchas décadas, utilizando ordenadores y tecnologías de la información de una manera
rudimentaria. A pesar de que se produce dentro de dicha industria gran cantidad de datos e
información en cada proyecto, además el intercambio de información entre cada uno de los
intervinientes en el proceso era de manera inconsistente, normalmente reducida a pequeños
conjuntos de datos y solamente a una parte de los agentes simultáneamente. Asimismo gran parte
de la información se acaba perdiendo. Alguna se genera en contradicción clara con otra del mismo
proyecto, o a veces es innecesariamente duplicada. Las asistencias en el proyecto basados en los
modelos computacionales son independientes y no permiten el intercambio de datos
automáticamente incluso si estos datos deben usarse por el mismo interviniente. Esto genera
frecuentes omisiones, repeticiones, confusiones, incomprensiones, errores, retrasos y hasta
posibles litigios. Estas circunstancias aumentan el coste y el plazo de construcción de los edificios.
El potencial del uso de los medios actuales informáticos es enorme, y además pueden ahorrar
dinero en los desarrollos de los proyectos. En Julio de 1.994 el artículo editado por Sir Michael
Latham sobre la industria de la construcción Británica, desafiaba a la construcción a ahorrar más del
30% del coste actual de los proyectos de edificios para el año 2.000. El artículo basaba gran parte
de este ahorro en el uso por parte de los agentes de las tecnologías de la información
5.2.- LA ALIANZA INTERNACIONAL POR LA

INTEROPERATIBILIDAD
En la primavera de 1.993, algunas de las principales compañías de la Industria de la Construcción en
Estados Unidos empezaron a debatir el camino para acercar las modernas tecnologías de la
información a dicha industria. Este grupo formó la Industry Alliance for Interoperatibility al principio
del verano de 1.994 e hicieron la primera demostración de la interoperatibilidad basada en
formatos CAD y herramientas de simulación durante la AEC Systems Show en Atlanta, Georgia en
Junio de 1.995. La alianza se convirtió en una organización pública, abierta a cualquier miembro de
la industria en Septiembre de 1.995 y formalmente se convirtió en una organización global en Mayo
de 1.996. En este momento se cambió el nombre por el de International Alliance for
Interoperatibility.
MBIMMA_M6T2_161005
42
SMART
La IAI está orientada a la acción, siendo una entidad sin ánimo de lucro. Su misión es definir,
publicar y promover especificaciones para el formato IFC. (Industry Foundation Class). Como una
base genérica y universal de intercambio de información entre todas las industrias de la
construcción y a lo largo de todo el ciclo de vida del edificio y a través de todas las disciplinas y
aplicaciones técnicas, IFC se define como un simple, orientado a objetos, modelo de datos de un
edificio. Los proyectos definidos en IFC deben tener la información exacta y libre de errores.
IFC es un formato abierto y gratuito, para la implementación por todos los miembros de la
industria. La implementación IFC del software es prioritario, para la protección de los datos.
En Junio de 1.997, IAI, tenía siete capítulos de miembros en Norteamérica, Europa y Asia, con tres
organizaciones más en Australia y Europa y un total de casi 500 miembros formados por
organizaciones y compañías. La organización está dirigida por el IAI International Council, cada
capítulo tiene su propio equipo formado por Directores, Coordinadores de los comités y varios
comités principales. Dos comités técnicos –Research/advidsory y Software implementation- son
internacionales e informan al International Technical Management Committee.
5.3.- IFC 1.0
La IAI anuncio la salida de la versión 1.0 del formato IFC en Junio de 1.996 y publico la End User
Guide (IAI, 1.996ª) además de un “pre-release” IFC 1.0 Specifications (IAI 1.996b) . La
documentación completa estuvo a disposición de los miembros del IAI por parte de sus respectivos
capítulos o por internet, conteniendo cuatro volúmenes adicionales los cuales describían:
 Los procesos que permitían la gestión del modelo
 Las especificaciones completas del modelo IFC 1.0
 El intercambio de archivos estático
 Runtime Interfaces.
IFC 1.0 consiste en un modelo principal orientado a objetos, cuatro modelos independientes de
recursos y cuatro extensiones de dominio iniciales (arquitectura, servicios del edificio, gestión de la
construcción y gestión del mantenimiento). El modelo principal o base definía objetos, atributos y
relaciones entre las extensiones de dominio. Los modelos de recursos definían la geometría,
unidades y utilidades comunes. Los modelos de extensión definían objetos, atributos y relaciones
no específicas entre los dominios.
MBIMMA_M6T2_161005
43
SMART
Con la publicación del IFC 1.0, 26 compañías de Estados Unidos, Canadá y Europa anunciaron su
intención de crean dentro de su software un compilador para el formato IFC, Estas compañías
comprendían las más importantes distribuidores de CAD: Autodesk, Bentley, Nemetscheck y IEZ.
Un pequeño grupo de implementadores piloto del IAI, mostraron en profundidad el concepto de

IFC 1.0 durante la AEC show en Frankfurt en Noviembre de 1.996. Cuatro compañías de software
(Autodesk and Bentley americanas, Nemetscheck y Softech, subsidiaria alemana de Softdesk, desde
Europa). Intercambiaron archivos que contenían datos geométricos. Este intercambio tuvo lugar
sobre versiones especiales del formato IFC programadas desde su software CAD particular.
Uno de los primeros modelos tridimensionales que se crearon en IFC fue el modelo de la célebre
casa Schroder, del arquitecto de De Stij, Gerrit Rietveld, fue modelada en un programa
determinado de CAD y traspasada a otro que pudo descifrar el archivo y crear un archivo 3D de su
propio software.
5.4.- HOJA DE RUTA DEL IAI
El plan de desarrollo del IFC está definido en la hoja de ruta del IAI. Proporciona la programación de
los lanzamientos futuros, define los nuevos procesos que tienen que ser compatibles con los
MBIMMA_M6T2_161005
44
SMART
nuevos lanzamientos e identifica las tecnologías necesarias para posibilitar los novedosos procesos.
También identifica nuevas oportunidades del mercado específicas de las nuevas funcionalidades. El
contenido de la hoja de ruta está constantemente evolucionando.
Los futuros lanzamientos de las versiones de IFC deben incluir nuevas extensiones de dominios y
expansión además de las ya existentes. El lanzamiento de la versión 2.0 incluirá tres diferentes tipos
de adiciones:
 Nuevos grupos de objetos/atributos/relaciones
 Nuevas tecnologías IFC
 Subconjuntos de dominios del modelo basados en elementos no IFC.
5.5.- BUILDINGSMART
A partir de la aparición de la versión IFC 2.0 la IAI, pasa a denominarse BuidingSmart, continuando
siendo una organización internacional de empresas de construcción sin ánimo de lucro.
Los objetivos principales de la asociación:
I. Promocionar el uso de BIM – Building Information Modelling – en todos los procesos relacionados
con el sector de la construcción, a lo largo de todo el ciclo de vida de sus productos.
II. Promocionar el uso de BIM – en todos los procesos de intercambio de información entre los
agentes relacionados con el sector de la construcción.
III. Promover y definir nuevos procesos de trabajo y de negocio para los diferentes agentes,
adaptados a la metodología BIM durante todo su ciclo de vida.
IV. Involucrar a todos los agentes participantes en la industria de la construcción en el uso de las
tecnologías BIM para mejorar los procesos de trabajo y de negocio tradicionales de un proyecto de
construcción:
a. Entidades que trabajan en la preparación y supervisión en el ámbito del diseño: ingenierías,

estudios de arquitectura.
b. Entidades que se dedican a la ejecución: constructoras.
c. Entidades que se dedican a la explotación.
d. Entidades que trabajan en el mantenimiento.
MBIMMA_M6T2_161005
45
SMART
e. Entidades que desarrollan o distribuyen aplicaciones software.
f. Fabricantes y distribuidores de materiales y componentes.
g. Organismos que realizan investigación: Universidades y Centros Tecnológicos.
h. Administraciones Públicas.
i. Propietarios de Edificios e Infraestructuras.
j. Colectivos de profesionales.
V. Promover y desarrollar estándares abiertos para el intercambio de información relacionado con

edificios e infraestructuras.
VI. Desarrollar guías y programas de formación que faciliten la adaptación a la metodología BIM a
los diferentes agentes participantes en la industria de la construcción
VII. Coordinar, promover y patrocinar actividades de investigación y desarrollo que favorezcan la

asimilación de la tecnología BIM en el sector de la construcción nacional.
VIII. Coordinar, promover y patrocinar actividades de difusión y promoción de las actividades

llevadas a cabo por la Asociación.
IX. Exponer los intereses de España en las decisiones que se tomen en la Building Smart
Internacional.
X. Promover métodos de contratación participativos
ESTRUCTURA ORGANIZATIVA Y FUNCIONAMIENTO
Son órganos de representación y de gobierno de BUILDINGSMART SPANISH CHAPTER la Asamblea

General de Asociados y la Junta Directiva. La Asamblea General es el órgano supremo de gobierno
de BUILDINGSMART SPANISH CHAPTER y estará integrada por todos sus Asociados de acuerdo a los
derechos que marcan estos Estatutos.
La Junta Directiva es el órgano permanente de gobierno, gestión, administración y dirección de la

Asociación. Estará formada por un Presidente, un Vicepresidente por cada comisión sectorial, un
Secretario, un Tesorero, un número de vocales compuesto por un miembro de cada comisión
sectorial y un representante de los Simpatizantes. De entre los Vicepresidentes designados por
cada comisión sectorial, la Junta Directiva elegirá un Vicepresidente Primero.
A modo meramente enunciativo, corresponde a la Junta Directiva las siguientes facultades y todo
cuanto con ellas esté relacionado, ampliamente y sin limitación alguna:
MBIMMA_M6T2_161005
46
SMART
・ Dirigir y controlar las actividades de la Asociación.
・ Elaborar los presupuestos anuales de ingresos y gastos, proponiendo las cuotas ordinarias de los
miembros.
・ Acordar la adquisición o pérdida de la condición de miembro de la Asociación sometida a la

ratificación por la Asamblea General.
・ Aprobar la constitución de las Comisiones.
・ Asumir la representación jurídica de la Asociación.
・ Preparar la Memoria Anual de las actividades, así como las cuentas del ejercicio para su
presentación a la Asamblea General.
・ Proponer a la Asamblea General el programa de actuación para cada ejercicio, así como las
políticas a desarrollar a medio y largo plazo.
・ Ejecutar o hacer que se ejecuten los acuerdos de la Asamblea General.
・ Proponer a la Asamblea General el nombramiento y la separación del Presidente, y el cese de

cualquier otro miembro de la Junta Directiva.
・ Nombrar y separar al Vicepresidente Primero, Secretario, Tesorero y representante de los

Simpatizantes.
・ Designar a las personas que ocupen temporalmente las vacantes que puedan ocurrir en la Junta
Directiva. La persona de este modo designada ocupará el cargo solamente por el plazo no vencido.
・ Juzgar actuaciones y disponer sanciones según los presentes Estatutos, y especialmente en el

caso en que exista una denuncia contra algún miembro de la Junta Directiva por otro miembro o
por terceros.
・ Resolver las reclamaciones contra decisiones o acuerdos tomados por el Presidente.
・ Cualquier actuación no reservada a la Asamblea General y a otros órganos.
・ Otorgar al Presidente de la Junta Directiva cuantos poderes se juzguen necesarios para el mejor
funcionamiento de la misma.
・ Crear, elegir coordinador, fijar los objetivos y disolver los Comités Temáticos y Territoriales.
・ Aceptar o rechazar a Simpatizantes y Patrocinadores y definir las distintas categorías de los

mismos y sus condiciones.
MBIMMA_M6T2_161005
47
SMART
・ En los casos no incluidos en el desarrollo de Fines y Actividades establecidos en el artículo 2º de

los presentes Estatutos de la Asociación, las facultades no enunciadas no suponen ampliación
indirecta de las mismas, sino mera autorización anticipada para la realización ocasional de tales
actos.
MBIMMA_M6T2_161005
48
SMART
6.- CONCLUSIONES
 Repasamos una breve historia de la implementación del entorno BIM dentro de la industria
de la construcción y una clasificación del software que trabaja en el entorno BIM.
 Definimos la interoperatibilidad y nos fijamos en dos características principales que debe

cumplir:
o Interoperatibilidad sintáctica
o Interoperatibilidad semántica
 Hemos visto los distintos métodos de interopertatibilidad, desde la interoperatibilidad

dentro de los programas propios de una determinada compañía de software, hasta el IFC y
los estándares abiertos.
 Hemos estudiado la estructura de la información dentro de estos estándares abiertos y

como cada uno de los programas pueden interpretar este formato abierto.
 Hemos aprendido que además del IFC existen más soluciones de interoperatibilidad pero
requieren conocimientos técnicos de programación.
 Hemos estudiado el principal formato que permite la interoperatibilidad que es el formato

IFC, entrando en la necesidad de su implementación, los datos que contiene y el lenguaje
que utiliza, como es su estructura, las versiones que existen de dicho formato. Hemos visto
también que podemos dividir la información en subconjuntos para distribuirla de una
manera más controlada.
 Hemos visto el formato COBie en contraposición al formato IFC, comprobando el uso del
mismo, sus condiciones, que información traspasa y para qué sirve dicha información, las
aplicaciones de dicho formato.
 Por último hemos visto una breve historia y funcionamiento de la asociación BuildingSmart,
que es la que promueve el mantenimiento y uso del formato de intercambio IFC.
MBIMMA_M6T2_161005
49
SMART
BIBLIOGRAFIA
En el texto hemos referido páginas Web y documentos que están en referencia a los temas
tratados, por lo que dichos documentos forman parte de la Bibliografía del presente tema.
Aun así debemos listar las páginas web más importantes en referencia a los temas tratados:
https://www.tekla.com/
https://es.wikipedia.org/wiki/Interoperabilidad
https://en.wikipedia.org/wiki/Comparison_of_computer-aided_design_editors
http://www.ifcworkshop.es/secciones/ifc/que_es.html
https://en.wikipedia.org/wiki/Industry_Foundation_Classes
http://www.iso.org/iso/catalogue_detail.htm?csnumber=51622
https://www.nationalbimlibrary.com/Content/BIMStandard/NBS-BIM-Object-Standard-
v1_2_1114.pdf
https://www.thenbs.com/knowledge/ifc-is-it-simply-misunderstood
https://www.nibs.org/?page=bsa_cobie
https://www.wbdg.org/resources/cobie.php
http://www.bimtaskgroup.org/cobie-uk-2012/
http://www.bimtaskgroup.org/cobie/
https://knowledge.autodesk.com/support/revit-products/learn-
explore/caas/simplecontent/content/cobie-extension-for-revit.html
http://www.caddmicrosystems.com/cobieextension/help/index.html
http://www.buildingsmart-tech.org/about-us
MBIMMA_M6T2_161005
50

Temario M6T2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Temario M6T2

Uploaded by

Copyright:

Available Formats

Tema 2.

Docente autor: Nombre del docente

4.5.- DESCRIPCIÓN DEL ARCHIVO .............................................................................................................. 38

1. EVOLUCIÓN DE LAS HERRAMIENTAS QUE

1.1.- UNA BREVE HISTORIA DE LAS HERRAMIENTAS DE

BIM no es un concepto nuevo, la siguiente sentencia describe perfectamente una

Augmenting Human Intellect, Douglas C. Engelbart, 1962,

En cuya introducción dice lo siguiente:

“Muchos de los costes de diseño, construcción y utilización de los edificios se derivan de la

Consideramos un edificio como la composición espacial de un conjunto de piezas. El sistema

1. Un sistema simple para introducir datos gráficos complejos.

2. Un lenguaje grafico interactivo para editar y componer conjuntos de elementos.

3. Capacidades gráficas para producir perspectivas o dibujos ortográficos de alta

4. Un tipo y capacidad de formato que permite la clasificación de la base de datos por

Este programa usaba componentes de bibliotecas individuales, un interface de usuario

BDS, fue creado por el profesor Charles Eastman

Aunque su uso fue únicamente de naturaleza experimental y no fue usado en proyectos

En 1.977 Avions Marcel Dassault https://es.wikipedia.org/wiki/Dassault_Aviation creó un

El Centre for Integrated Facility Engineering (CIFE), se fundó en la Universidad de Stanford

Pero este no es ni siquiera el primer ejemplo de prefabricación digital en la

En 1.997 Irwin Jungreis http://www.csail.mit.edu/user/2095 y Leonid Raiz

creado un software llamado Revit, Revit incorporaba un motor de cambios paramétricos.

Estoy seguro que el sistema BIM va a provocar una revolución en la representación y

1.2.- Clasificación del software que trabaja en entorno BIM.

 No es software ni tecnología, (es un proceso posible debido a la tecnología)

 No se puede comprar en una caja

 No es algo que un técnico de CAD hace de forma aislada

BIM TRATA FUNDAMENTALMENTE SOBRE COMPARTIR

La tecnología BIM se puede clasificar de la siguiente forma:

INTEROPERATIBILIDAD FUNDAMENTALMENTE ES LA IDEA DE

Hay fundamentalmente dos tipos de interoperatibilidad:

2.1.- INTEROPERATIBILIDAD SINTACTICA

 Σύν: (syn): significa: acuerdo

 Τάξις: (táxis): significa: ordenar

Para que exista una Interoperatibilidad sintáctica debe haber:

 Formatos específicos de datos

2.2.- INTEROPERATIBILIDAD SEMANTICA

 La relación entre significado, como palabras, frases, signos o símbolos y su denotación: lo

Más allá de la capacidad de los sistemas computacionales de intercambiar datos, la

El contenido de la información no debe contener ambigüedades.

2.3. MÉTODOS DE INTEROPERATIBILIDAD

Vamos a ver el siguiente ejemplo, OASYS, http://www.oasys-

2.3.2.- ENLACES DE SOFTWARE DE SINTACTICA ABIERTA

 STEP (Estándar for the Exchange of Product model data)

2.3.3.- IFC Y ESTANDARES ABIERTOS

IFC es probablemente el más conocido “Open Standar” de interoperatibilidad dentro de la industria

La competitividad será posible debido a:

 El interface del usuario

 Los productos (IfcProduct) están divididos en elementos espaciales (IfcSpace), elementos

 Los productos contienen información sobre el material, su representación (geometría),

 Los recursos (IfcResources) contienen información acerca de materiales, mano de obra,

IFC es un modelo de relaciones entre las entidades.

 IfcWall (elemento del edificio)

 IfcCartesianPoint (Construcción básica)

Las entidades raíz contienen los siguientes puntos:

 IfcObjectDefinition (Tipos y definiciones)

 IfcRelationship (Relaciones entre objetos)

 IfcPropertyDefinition (propiedades del objeto)

Hay cantidad de software, que tiene capacidad de leer y escribir IFC.

2.3.4.- ESTRUCTURA DE LA INFORMACIÓN

Las herramientas que actualmente usamos en la industria de la construcción afecta a la capacidad

Para la elección se debe tener en cuenta las siguientes cuestiones:

 ¿Son todos los datos realmente compatibles?